match on more ure(4) devices
match on additional device ids from lenovo windows driver https://download.lenovo.com/consumer/options/thinkpad_usb-c_dock_gen2_drivers_v1.0.3.03241.exe and linux driver Index: usbdevs === RCS file: /cvs/src/sys/dev/usb/usbdevs,v retrieving revision 1.720 diff -u -p -r1.720 usbdevs --- usbdevs 3 Aug 2020 14:25:44 - 1.720 +++ usbdevs 4 Oct 2020 04:47:48 - @@ -80,6 +80,7 @@ vendor FUJITSUCOMP0x0430 Fujitsu Compon vendor TAUGA 0x0436 Taugagreining HF vendor AMD 0x0438 Advanced Micro Devices vendor LEXMARK 0x043d Lexmark International +vendor LG 0x043e LG USA vendor NANAO 0x0440 NANAO vendor ALPS0x044e Alps Electric vendor THRUST 0x044f Thrustmaster @@ -367,6 +368,7 @@ vendor TOSHIBA 0x0930 Toshiba Corp vendor INTREPIDCS 0x093c Intrepid vendor YANO0x094f Yano vendor KINGSTON0x0951 Kingston Technology +vendor NVIDIA 0x0955 NVIDIA vendor BLUEWATER 0x0956 BlueWater Systems vendor AGILENT 0x0957 Agilent Technologies vendor GUDE0x0959 Gude ADS @@ -465,6 +467,7 @@ vendor ITEGNO 0x0eba iTegno vendor NORITAKE0x0eda Noritake itron Corp vendor EGALAX 0x0eef eGalax vendor XIRING 0x0f14 XIRING +vendor IOI 0x0f21 IOI vendor AIRPRIME0x0f3d Airprime vendor VTECH 0x0f88 VTech vendor FALCOM 0x0f94 Falcom Wireless Communications @@ -476,6 +479,7 @@ vendor UNKNOWN4 0x0fe6 Unknown Vendor vendor DVICO 0x0fe9 DViCO vendor QUALCOMM2 0x1004 Qualcomm vendor MOTOROLA4 0x100d Motorola +vendor TTL 0x1025 Technology Testing Lab vendor HP3 0x103c Hewlett Packard vendor THURLBY 0x103e Thurlby Thandar Instruments vendor GIGABYTE0x1044 GIGABYTE @@ -540,6 +544,7 @@ vendor STARTECH 0x14b0 StarTech.com vendor CONCEPTRONIC2 0x14b2 Conceptronic vendor SUPERTOP0x14cd SuperTop vendor PLANEX3 0x14ea Planex Communications +vendor TWINHEAD0x14ff Twinhead vendor SILICONPORTALS 0x1527 Silicon Portals vendor UBLOX 0x1546 U-blox vendor OWEN0x1555 Owen @@ -620,6 +625,7 @@ vendor VERTEX 0x1fe7 Vertex Wireless Co vendor DLINK 0x2001 D-Link vendor PLANEX2 0x2019 Planex Communications vendor ENCORE 0x203d Encore +vendor LUXSHARE0x208e Luxshare vendor PARA0x20b8 PARA Industrial vendor TRENDNET0x20f4 TRENDnet vendor RTSYSTEMS 0x2100 RT Systems @@ -635,7 +641,11 @@ vendor XIAOMI 0x2717 Xiaomi vendor NHJ 0x2770 NHJ vendor THINGM 0x27b8 ThingM vendor ASUSTEK 0x2821 ASUSTeK Computer +vendor PIONEERDJ 0x2b73 Pioneer DJ vendor PLANEX 0x2c02 Planex Communications +vendor CLUB3D 0x2d1c Club 3D +vendor CLEVO 0x30da CLEVO +vendor DYNABOOK0x30f3 Dynabook vendor LINKINSTRUMENTS 0x3195 Link Instruments vendor AEI 0x3334 AEI vendor PQI 0x3538 PQI @@ -1056,6 +1066,7 @@ product ASUS RTL8192CU0x17ab RTL8192CU product ASUS USBN660x17ad USB-N66 product ASUS RTL8192CU_2 0x17ba RTL8192CU product ASUS RTL8192CU_3 0x17c0 RTL8192CU +product ASUS RTL8156 0x18d1 RTL8156 product ASUS MYPAL_A7300x4202 MyPal A730 product ASUS2 USBN11 0x0b05 USB-N11 @@ -1194,6 +1205,8 @@ product BELKIN F5U234 0x0234 F5U234 USB product BELKIN F5U237 0x0237 F5U237 USB 2.0 7-Port Hub product BELKIN F5U257 0x0257 F5U257 Serial product BELKIN F6H375 0x0375 F6H375 UPS +product BELKIN RTL8152B0x047a RTL8152B +product BELKIN RTL8153 0x048a RTL8153 product BELKIN F5U409 0x0409 F5U409 Serial product BELKIN F6C550AVR 0x0551 F6C550-AVR UPS product BELKIN F6C1250EITWRK 0x0750 F6C1250EITW-RK UPS @@ -1336,9 +1349,13 @@ product CISCOLINKSYS WUSBF54G0x0024 WUS product CISCOLINKSYS WUSB200 0x0028 WUSB200 product CISCOLINKSYS AE10000x002f AE1000 product CISCOLINKSYS AM10 0x0031 AM10 +product CISCOLINKSYS USB3GIGV1 0x0041 USB3GIGV1 product CISCOLINKSYS2 RT3070 0x4001 RT3070 product CISCOLINKSYS3 RT3070 0x0101 RT3070 +/* CLEVO products */ +product CLEVO RTL8153B 0x5101 RTL8153B + /* Clipsal products */ product CLIPSAL 560884 0x0101 560884 C-Bus Switch product CLIPSAL 5500PACA 0x0201 5500PACA C-Bus Controller @@ -1348,6 +1365,9 @@ product CLIPSAL 5000CT2 0x0304 5000CT2 product CLIPSAL C5000CT2 0x0305 C5000CT2 C-Bus Touch Screen product CLIPSAL L51XX 0x0401 L51xx C-Bus
scsi_xfer pool exhausted! (syzkaller machine)
I just hit the endless "scsi_xfer pool exhausted!" stream that others reported over the years. I don't believe people previously found a satisfactory resolution to the problem. The machine in question is a Google Compute Engine VM (I found reports of vmware VM with this symptom). One thing I observed is syz-bot abuses the machine pretty badly. It runs a ton of golang compilations in parallel and they exhaust the 24G of RAM which makes the machine very slow. jca@ hypothesized that when a system runs with elevated memory pressure it is likely to hit this problem. So, I'll increase the amount of RAM for the VM to match what linux bot has. I'll also pick up the most recent snapshot, while I'm here. Now, is there any value in trying to follow scxspl pool utilization while the system is running? Do we have a more pointed tool than systat for that? Right now systat reports scxspl 200 736552 0 2 352 348 4 14 0 8 3 The machine just finished rebuilding syzkaller and churning through a kernel build. Thanks Greg OpenBSD 6.8-beta (GENERIC.MP) #54: Mon Aug 31 18:15:42 MDT 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 25753014272 (24559MB) avail mem = 24957480960 (23801MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xbc90 (22 entries) bios0: vendor Google version "Google" date 01/01/2011 bios0: Google Google Compute Engine acpi0 at bios0: ACPI 2.0 acpi0: sleep states S3 S4 S5 acpi0: tables DSDT FACP SRAT APIC SSDT WAET acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU @ 2.30GHz, 2300.33 MHz, 06-3f-00 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 990MHz cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU @ 2.30GHz, 2276.87 MHz, 06-3f-00 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: disabling user TSC (skew=-485) cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) CPU @ 2.30GHz, 2276.89 MHz, 06-3f-00 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Xeon(R) CPU @ 2.30GHz, 2276.90 MHz, 06-3f-00 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Xeon(R) CPU @ 2.30GHz, 2276.91 MHz, 06-3f-00 cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,ARAT,XSAVEOPT,MELTDOWN cpu4: 256KB 64b/line 8-way L2 cache cpu4: smt 1, core 0, package 0 cpu5 at mainbus0: apid 3 (application processor) cpu5: Intel(R) Xeon(R) CPU @ 2.30GHz, 2276.89 MHz, 06-3f-00 cpu5: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,ARAT,XSAVEOPT,MELTDOWN cpu5: 256KB 64b/line 8-way L2 cache cpu5: smt 1, core 1, package 0 cpu6 at mainbus0: apid 5
Re: Make df output more human friendly in daily(8)
On Sat, 3 Oct 2020 13:53:13 +0100, Stuart Henderson wrote: > > +next_part "Backing up filesystems with dump:" > > +dump w | grep -vB1 ^Dump > > The "next_part" header text is wrong, it isn't doing a backup here, > it's only reporting which need to be dumped. Thanks! Here's a version with +next_part "Filesystems which need to be dumped:" Index: etc/daily === RCS file: /cvs/src/etc/daily,v retrieving revision 1.93 diff -u -p -r1.93 daily --- etc/daily 9 Sep 2019 20:02:26 - 1.93 +++ etc/daily 3 Oct 2020 21:13:25 - @@ -136,21 +136,8 @@ done next_part "Services that should be running but aren't:" rcctl ls failed -next_part "Checking subsystem status:" -if [ "X$VERBOSESTATUS" != X0 ]; then - echo "" - echo "disks:" - df -ikl - echo "" - dump W -else - dump w | grep -vB1 ^Dump -fi - -next_part "network:" -if [ "X$VERBOSESTATUS" != X0 ]; then - netstat -ivn -fi +next_part "Filesystems which need to be dumped:" +dump w | grep -vB1 ^Dump next_part "Running calendar in the background:" if [ "X$CALENDAR" != X0 -a \ Index: share/man/man8/daily.8 === RCS file: /cvs/src/share/man/man8/daily.8,v retrieving revision 1.28 diff -u -p -r1.28 daily.8 --- share/man/man8/daily.8 26 Jul 2020 13:27:24 - 1.28 +++ share/man/man8/daily.8 3 Oct 2020 21:13:25 - @@ -114,15 +114,9 @@ Lists any daemons which are enabled in .Xr rc.conf.local 8 but which are not actually running. .It -Checks disk status. -Reports on the amount of disk used/available via -.Xr df 1 . Reports on which file systems need to be dumped via .Xr dump 8 . .It -Reports networking statistics via -.Xr netstat 1 . -.It Runs the .Xr calendar 1 utility unless the environment variable @@ -205,15 +199,6 @@ If set to 1, run with the no-write flag. .It Ev ROOTBACKUP If set to 1, make a backup of the root file system. -.It Ev VERBOSESTATUS -If set to 0, -.Xr df 1 , -.Xr dump 8 , -and -.Xr netstat 1 -are skipped. -Consequently, if none of the other commands produce any output, -no mail will be sent to root. .El .Pp The following variables can be set in @@ -250,9 +235,7 @@ Root .Sh SEE ALSO .Xr calendar 1 , .Xr crontab 1 , -.Xr df 1 , .Xr locate 1 , -.Xr netstat 1 , .Xr rdist 1 , .Xr whatis 1 , .Xr crontab 5 , Index: share/man/man8/afterboot.8 === RCS file: /cvs/src/share/man/man8/afterboot.8,v retrieving revision 1.165 diff -u -p -r1.165 afterboot.8 --- share/man/man8/afterboot.8 9 Feb 2020 16:36:02 - 1.165 +++ share/man/man8/afterboot.83 Oct 2020 21:13:25 - @@ -458,8 +458,6 @@ to understand what the periodic system m how to customize them: For example, to enable .Ev ROOTBACKUP -or to disable -.Ev VERBOSESTATUS , or to add local maintenance code to .Pa /etc/daily.local , /etc/weekly.local , or
Re: Make df output more human friendly in daily(8)
Hi Daniel/Ingo, On Fri, 2 Oct 2020 15:41:31 -0400 Daniel Jakots wrote: > +next_part "Backing up filesystems with dump:" > +dump w | grep -vB1 ^Dump That command doesn't dump disks. w shows the operator what to dump. Cheers, Craig.
arm64 dt(4) improvements
Diff below has two dt(4) improvements. It fixes the construction of the call frame that accompanies the stack frame. Currently it sticks the saved copy of the LR register in there. But instead it should stick the value of the ELR in there to record the location where the trap happened. This fixes stack traces through traps. Then it adds the magic defines to strip off the frames that are't interesting. ok? Index: dev/dt/dt_dev.c === RCS file: /cvs/src/sys/dev/dt/dt_dev.c,v retrieving revision 1.10 diff -u -p -r1.10 dt_dev.c --- dev/dt/dt_dev.c 28 Sep 2020 13:16:58 - 1.10 +++ dev/dt/dt_dev.c 3 Oct 2020 17:54:20 - @@ -56,6 +56,9 @@ #if defined(__amd64__) #define DT_FA_PROFILE 5 #define DT_FA_STATIC 2 +#elif defined(__arm64__) +#define DT_FA_PROFILE 7 +#define DT_FA_STATIC 2 #elif defined(__powerpc64__) #define DT_FA_PROFILE 6 #define DT_FA_STATIC 2 Index: arch/arm64/arm64/exception.S === RCS file: /cvs/src/sys/arch/arm64/arm64/exception.S,v retrieving revision 1.11 diff -u -p -r1.11 exception.S --- arch/arm64/arm64/exception.S17 Mar 2020 17:27:12 - 1.11 +++ arch/arm64/arm64/exception.S3 Oct 2020 17:54:21 - @@ -38,7 +38,6 @@ sub sp, sp, #128 .endif sub sp, sp, #(TF_SIZE + 16) - stp x29, x30, [sp, #(TF_SIZE)] stp x28, x29, [sp, #(TF_X + 28 * 8)] stp x26, x27, [sp, #(TF_X + 26 * 8)] stp x24, x25, [sp, #(TF_X + 24 * 8)] @@ -60,6 +59,7 @@ mrs x18, sp_el0 .endif mov fp, x18 + stp x29, x10, [sp, #(TF_SIZE)] stp x10, x11, [sp, #(TF_ELR)] stp x18, lr, [sp, #(TF_SP)] mrs x18, tpidr_el1
ls: match historic behavior listing empty directories
This is adapted from FreeBSD revs 130236 and 130237 which have the
following log message:
If we are asked to print the total number of blocks, do so even if we
have no entries to print (either due to an empty directory or an
error). This makes the -l and -s options more consistent, like
Solaris and (Debian) Linux. To make this happen, tweak two
optimizations on the second call to display():
- Don't skip display() altogether, even if list == NULL.
- Don't skip the call to the printfn in display() if we
need to print the total.
I've verified that both historic AT ls and GNU ls behave this
way.
- todd
Index: bin/ls/ls.c
===
RCS file: /cvs/src/bin/ls/ls.c,v
retrieving revision 1.53
diff -u -p -u -r1.53 ls.c
--- bin/ls/ls.c 6 Jul 2020 00:55:05 - 1.53
+++ bin/ls/ls.c 3 Oct 2020 15:18:01 -
@@ -355,7 +355,13 @@ traverse(int argc, char *argv[], int opt
fts_open(argv, options, f_nosort ? NULL : mastercmp)) == NULL)
err(1, NULL);
- display(NULL, fts_children(ftsp, 0));
+ /*
+* We ignore errors from fts_children here since they will be
+* replicated and signalled on the next call to fts_read() below.
+*/
+ chp = fts_children(ftsp, 0);
+ if (chp != NULL)
+ display(NULL, chp);
if (f_listdir)
return;
@@ -438,16 +444,6 @@ display(FTSENT *p, FTSENT *list)
char buf[21]; /* 64 bits == 20 digits */
char *flags = NULL;
- /*
-* If list is NULL there are two possibilities: that the parent
-* directory p has no children, or that fts_children() returned an
-* error. We ignore the error case since it will be replicated
-* on the next call to fts_read() on the post-order visit to the
-* directory p, and will be signalled in traverse().
-*/
- if (list == NULL)
- return;
-
needstats = f_inode || f_longform || f_size;
flen = 0;
btotal = maxblock = maxinode = maxlen = maxnlink = 0;
@@ -542,7 +538,13 @@ display(FTSENT *p, FTSENT *list)
++entries;
}
- if (!entries)
+ /*
+* If there are no entries to display, we normally stop right
+* here. However, we must continue if we have to display the
+* total block count. In this case, we display the total only
+* on the second (p != NULL) pass.
+*/
+ if (!entries && (!(f_longform || f_size) || p == NULL))
return;
d.list = list;
Index: bin/ls/print.c
===
RCS file: /cvs/src/bin/ls/print.c,v
retrieving revision 1.38
diff -u -p -u -r1.38 print.c
--- bin/ls/print.c 5 Feb 2019 02:17:32 - 1.38
+++ bin/ls/print.c 3 Oct 2020 15:13:14 -
@@ -87,7 +87,8 @@ printlong(DISPLAY *dp)
NAMES *np;
char buf[20];
- if (dp->list->fts_level != FTS_ROOTLEVEL && (f_longform || f_size))
+ if ((dp->list == NULL || dp->list->fts_level != FTS_ROOTLEVEL) &&
+ (f_longform || f_size))
(void)printf("total %llu\n", howmany(dp->btotal, blocksize));
for (p = dp->list; p; p = p->fts_link) {
@@ -198,7 +199,8 @@ printcol(DISPLAY *dp)
if (num % numcols)
++numrows;
- if (dp->list->fts_level != FTS_ROOTLEVEL && (f_longform || f_size))
+ if ((dp->list == NULL || dp->list->fts_level != FTS_ROOTLEVEL) &&
+ (f_longform || f_size))
(void)printf("total %llu\n", howmany(dp->btotal, blocksize));
for (row = 0; row < numrows; ++row) {
for (base = row, col = 0;;) {
@@ -271,7 +273,8 @@ printacol(DISPLAY *dp)
if ( (colwidth = compute_columns(dp, )) == 0)
return;
- if (dp->list->fts_level != FTS_ROOTLEVEL && (f_longform || f_size))
+ if ((dp->list == NULL || dp->list->fts_level != FTS_ROOTLEVEL) &&
+ (f_longform || f_size))
(void)printf("total %llu\n", howmany(dp->btotal, blocksize));
col = 0;
for (p = dp->list; p; p = p->fts_link) {
Re: Support astfb(4) in wsfb(4)
On Sat, Oct 03, 2020 at 04:50:28PM +0200, Mark Kettenis wrote:
> The astfb(4) is a little-endian framebuffer on a (for now) big-endian
> architecture. Therefore we need to tell X that the pixels have their
> color components laid out in a non-standard way.
>
> Note that support for this pixel layout in X is weak. Normal stuff
> works but the software rendering in Mesa doesn't seem to work
> properly. So while this is good enough to get a bunch of xterms on
> the screen, glxgears will have the wrong colors.
>
> ok?
yes, ok.
>
> P.S. I don't think basing on the wsdisplay type is the right thing to
> do, but it is what we have done in the past. Maybe we should
> extend wsdisplay_fbinfo with some fields that communicate the
> pixel format and use that?
>
>
> Index: driver/xf86-video-wsfb/src/wsfb_driver.c
> ===
> RCS file: /cvs/xenocara/driver/xf86-video-wsfb/src/wsfb_driver.c,v
> retrieving revision 1.38
> diff -u -p -r1.38 wsfb_driver.c
> --- driver/xf86-video-wsfb/src/wsfb_driver.c 27 Jul 2019 07:48:19 -
> 1.38
> +++ driver/xf86-video-wsfb/src/wsfb_driver.c 3 Oct 2020 14:39:18 -
> @@ -632,6 +632,17 @@ WsfbPreInit(ScrnInfoPtr pScrn, int flags
> masks.blue = 0x1f;
> }
> break;
> + case WSDISPLAY_TYPE_ASTFB:
> + if (pScrn->depth > 16) {
> + masks.red = 0xff00;
> + masks.green = 0x00ff;
> + masks.blue = 0xff00;
> + } else {
> + masks.red = 0x1f;
> + masks.green = 0x3f << 5;
> + masks.blue = 0x1f << 11;
> + }
> + break;
> default:
> masks.red = 0;
> masks.green = 0;
--
Matthieu Herrb
Re: pthread_spin_unlock and ownership behaviour
> For shits and giggles I deceided to look into pthread_spin_unlock and > saw that we return EPERM here, while POSIX states that this behaviour > is unconditionally undefined.[0] Is there a reason why we shouldn't > abort here as well? Undefined doesn't mean it can turn into a bowl of petunias. As a general rule, it is completely terrible if base libraries abort, it is terrible if programs dump core in a directory for an inexplicit reason which is hard to diagnose from the corefile. And have you read abort.c? It does and performs multiple system calls before actually dying..
Support astfb(4) in wsfb(4)
The astfb(4) is a little-endian framebuffer on a (for now) big-endian
architecture. Therefore we need to tell X that the pixels have their
color components laid out in a non-standard way.
Note that support for this pixel layout in X is weak. Normal stuff
works but the software rendering in Mesa doesn't seem to work
properly. So while this is good enough to get a bunch of xterms on
the screen, glxgears will have the wrong colors.
ok?
P.S. I don't think basing on the wsdisplay type is the right thing to
do, but it is what we have done in the past. Maybe we should
extend wsdisplay_fbinfo with some fields that communicate the
pixel format and use that?
Index: driver/xf86-video-wsfb/src/wsfb_driver.c
===
RCS file: /cvs/xenocara/driver/xf86-video-wsfb/src/wsfb_driver.c,v
retrieving revision 1.38
diff -u -p -r1.38 wsfb_driver.c
--- driver/xf86-video-wsfb/src/wsfb_driver.c27 Jul 2019 07:48:19 -
1.38
+++ driver/xf86-video-wsfb/src/wsfb_driver.c3 Oct 2020 14:39:18 -
@@ -632,6 +632,17 @@ WsfbPreInit(ScrnInfoPtr pScrn, int flags
masks.blue = 0x1f;
}
break;
+ case WSDISPLAY_TYPE_ASTFB:
+ if (pScrn->depth > 16) {
+ masks.red = 0xff00;
+ masks.green = 0x00ff;
+ masks.blue = 0xff00;
+ } else {
+ masks.red = 0x1f;
+ masks.green = 0x3f << 5;
+ masks.blue = 0x1f << 11;
+ }
+ break;
default:
masks.red = 0;
masks.green = 0;
Re: Make df output more human friendly in daily(8)
On 2020/10/03 08:44, Daniel Jakots wrote: > On Sat, 3 Oct 2020 08:00:44 +0200, Ingo Schwarze > wrote: > > > But this needs to remain: > > > > > -Reports on which file systems need to be dumped via > > > -.Xr dump 8 . > > > -.It > > Indeed, I wrongly assumed that the other dump call was silent. Here's > the updated diff: > -if [ "X$VERBOSESTATUS" != X0 ]; then > - netstat -ivn > -fi > +next_part "Backing up filesystems with dump:" > +dump w | grep -vB1 ^Dump The "next_part" header text is wrong, it isn't doing a backup here, it's only reporting which need to be dumped.
Re: Make df output more human friendly in daily(8)
On Sat, 3 Oct 2020 08:00:44 +0200, Ingo Schwarze wrote: > But this needs to remain: > > > -Reports on which file systems need to be dumped via > > -.Xr dump 8 . > > -.It Indeed, I wrongly assumed that the other dump call was silent. Here's the updated diff: Index: share/man/man8/daily.8 === RCS file: /cvs/src/share/man/man8/daily.8,v retrieving revision 1.28 diff -u -p -r1.28 daily.8 --- share/man/man8/daily.8 26 Jul 2020 13:27:24 - 1.28 +++ share/man/man8/daily.8 3 Oct 2020 12:40:12 - @@ -114,15 +114,9 @@ Lists any daemons which are enabled in .Xr rc.conf.local 8 but which are not actually running. .It -Checks disk status. -Reports on the amount of disk used/available via -.Xr df 1 . Reports on which file systems need to be dumped via .Xr dump 8 . .It -Reports networking statistics via -.Xr netstat 1 . -.It Runs the .Xr calendar 1 utility unless the environment variable @@ -205,15 +199,6 @@ If set to 1, run with the no-write flag. .It Ev ROOTBACKUP If set to 1, make a backup of the root file system. -.It Ev VERBOSESTATUS -If set to 0, -.Xr df 1 , -.Xr dump 8 , -and -.Xr netstat 1 -are skipped. -Consequently, if none of the other commands produce any output, -no mail will be sent to root. .El .Pp The following variables can be set in @@ -250,9 +235,7 @@ Root .Sh SEE ALSO .Xr calendar 1 , .Xr crontab 1 , -.Xr df 1 , .Xr locate 1 , -.Xr netstat 1 , .Xr rdist 1 , .Xr whatis 1 , .Xr crontab 5 , Index: share/man/man8/afterboot.8 === RCS file: /cvs/src/share/man/man8/afterboot.8,v retrieving revision 1.165 diff -u -p -r1.165 afterboot.8 --- share/man/man8/afterboot.8 9 Feb 2020 16:36:02 - 1.165 +++ share/man/man8/afterboot.83 Oct 2020 12:40:12 - @@ -458,8 +458,6 @@ to understand what the periodic system m how to customize them: For example, to enable .Ev ROOTBACKUP -or to disable -.Ev VERBOSESTATUS , or to add local maintenance code to .Pa /etc/daily.local , /etc/weekly.local , or Index: etc/daily === RCS file: /cvs/src/etc/daily,v retrieving revision 1.93 diff -u -p -r1.93 daily --- etc/daily 9 Sep 2019 20:02:26 - 1.93 +++ etc/daily 3 Oct 2020 12:40:12 - @@ -136,21 +136,8 @@ done next_part "Services that should be running but aren't:" rcctl ls failed -next_part "Checking subsystem status:" -if [ "X$VERBOSESTATUS" != X0 ]; then - echo "" - echo "disks:" - df -ikl - echo "" - dump W -else - dump w | grep -vB1 ^Dump -fi - -next_part "network:" -if [ "X$VERBOSESTATUS" != X0 ]; then - netstat -ivn -fi +next_part "Backing up filesystems with dump:" +dump w | grep -vB1 ^Dump next_part "Running calendar in the background:" if [ "X$CALENDAR" != X0 -a \
Re: pthread_spin_unlock and ownership behaviour
Ports-wise, from a Nov 2019 build on i386, these used it: $ grep -Rl pthread_spin_unlock wrkscan wrkscan/devel/libivykis wrkscan/x11/gnustep/base wrkscan/x11/e17/eina wrkscan/misc/posixtestsuite wrkscan/net/libunbound wrkscan/net/libshout wrkscan/net/icecast wrkscan/net/bird/1,-doc wrkscan/net/bird/1,-main,v6 wrkscan/net/bird/2 wrkscan/net/strongswan wrkscan/mail/mailest wrkscan/geo/gdal,-main -- Sent from a phone, apologies for poor formatting. On 3 October 2020 10:45:05 Martijn van Duren wrote: Back in 2012 kurt@ added an abort call for the undefined behaviour cases on pthread_mutex_unlock. This helped me a great deal in examining the cause of some weird behaviour in icinga (or in the case of openbsd, just plain crash). For shits and giggles I deceided to look into pthread_spin_unlock and saw that we return EPERM here, while POSIX states that this behaviour is unconditionally undefined.[0] Is there a reason why we shouldn't abort here as well? I don't have a particular usecase for this, but the mutex case helped me and it only seems like the right thing to do from a semetrical point of view. The only cases of pthread_spin_unlock in base I found were in libunbound (which with my testing with unwind didn't caused any issues) and gnu/llvm/compiler-rt/lib/tsan, which I don't know where to test. I have no idea which ports use it. martijn@ [0] https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_spin_unlock.html Index: librthread/rthread_spin_lock.c === RCS file: /cvs/src/lib/librthread/rthread_spin_lock.c,v retrieving revision 1.5 diff -u -p -r1.5 rthread_spin_lock.c --- librthread/rthread_spin_lock.c 6 Apr 2020 00:01:08 - 1.5 +++ librthread/rthread_spin_lock.c 3 Oct 2020 09:42:21 - @@ -102,12 +102,12 @@ pthread_spin_unlock(pthread_spinlock_t * pthread_spinlock_t l; if (lock == NULL || *lock == NULL) - return (EINVAL); + abort(); l = *lock; if (l->owner != self) - return (EPERM); + abort(); l->owner = NULL; _spinunlock(>lock); Index: libpthread/man/pthread_spin_unlock.3 === RCS file: /cvs/src/lib/libpthread/man/pthread_spin_unlock.3,v retrieving revision 1.3 diff -u -p -r1.3 pthread_spin_unlock.3 --- libpthread/man/pthread_spin_unlock.36 Apr 2020 00:01:08 - 1.3 +++ libpthread/man/pthread_spin_unlock.33 Oct 2020 09:42:21 - @@ -38,17 +38,14 @@ functions. .Sh RETURN VALUES If successful, .Fn pthread_spin_unlock -returns zero; otherwise an error number is returned to indicate the error. +returns zero. .Sh ERRORS .Fn pthread_spin_unlock -will fail if: -.Bl -tag -width Er -.It Bq Er EINVAL -The value specified by +will call +.Xr abort 3 +if the value specified by .Fa lock -is invalid. -.It Bq Er EPERM -The lock is not owned by the calling thread. +is invalid or if the lock is not owned by the calling thread. .El .Sh SEE ALSO .Xr pthread_spin_init 3 ,
Re: mmap: Do not push KERNEL_LOCK() too far
> Date: Fri, 2 Oct 2020 10:32:27 +0200
> From: Martin Pieuchot
>
> On 01/10/20(Thu) 21:44, Mark Kettenis wrote:
> > > Date: Thu, 1 Oct 2020 14:10:56 +0200
> > > From: Martin Pieuchot
> > >
> > > While studying a bug report from naddy@ in 2017 when testing guenther@'s
> > > amap/anon locking diff I figured out that we have been too optimistic in
> > > the !MAP_ANON case.
> > >
> > > The reported panic involves, I'd guess, a race between fd_getfile() and
> > > vref():
> > >
> > > panic: vref used where vget required
> > > db_enter() at db_enter+0x5
> > > panic() at panic+0x129
> > > vref(ff03b20d29e8) at vref+0x5d
> > > uvn_attach(101,ff03a5879dc0) at uvn_attach+0x11d
> > > uvm_mmapfile(7,ff03a5879dc0,2,1,13,10012) at uvm_mmapfile+0x12c
> > > sys_mmap(c50,8000225f82a0,1) at sys_mmap+0x604
> > > syscall() at syscall+0x279
> > > --- syscall (number 198) ---
> > > end of kernel
> > >
> > > Removing the KERNEL_LOCK() from file mapping was out of the scope of this
> > > previous work, so I'd like to go back to a single KERNEL_LOCK/UNLOCK dance
> > > in this code path to remove any false positive.
> > >
> > > Note that this code is currently always run under KERNEL_LOCK() so this
> > > will only have effect once the syscall will be unlocked.
> > >
> > > ok?
> >
> > Hmm, I thought fd_getfile() was fully mpsafe.
>
> It is to get a reference on `fp'. However if the current thread
> releases the KERNEL_LOCK() before calling vref(9) it might lose a
> race.
I don't see the race. The function returns a 'fp' with a reference,
so 'fp' will be valid regardless of whether we hold the kernel lock or
not. So we should be able to take the kernel lock after the
fd_getfile() call isn't it?
> > But I suppose the kernel lock needs to be grabbed before we start
> > looking at the vnode?
>
> Yes, or to say it otherwise not released.
So the problem is that while we have an 'fp', its f_data member points
to a vnode that has already been put on the freelist and therefore has
v_usecount set to zero? How does that happen?
> > Your diff makes the locking a bit convoluted, but I suppose adding a
> > KERNEL_UNLOCK() before every "goto out" is worse?
>
> I tried to keep the diff as small as possible to not obfuscate the change.
> If we want cleaner code we can move the !ANON case in a different function.
Splitting would be hard because of the "goto is_anon".
> > > Index: uvm/uvm_mmap.c
> > > ===
> > > RCS file: /cvs/src/sys/uvm/uvm_mmap.c,v
> > > retrieving revision 1.161
> > > diff -u -p -r1.161 uvm_mmap.c
> > > --- uvm/uvm_mmap.c4 Mar 2020 21:15:39 - 1.161
> > > +++ uvm/uvm_mmap.c28 Sep 2020 09:48:26 -
> > > @@ -288,8 +288,11 @@ sys_mmap(struct proc *p, void *v, regist
> > >
> > > /* check for file mappings (i.e. not anonymous) and verify file. */
> > > if ((flags & MAP_ANON) == 0) {
> > > - if ((fp = fd_getfile(fdp, fd)) == NULL)
> > > - return (EBADF);
> > > + KERNEL_LOCK();
> > > + if ((fp = fd_getfile(fdp, fd)) == NULL) {
> > > + error = EBADF;
> > > + goto out;
> > > + }
> > >
> > > if (fp->f_type != DTYPE_VNODE) {
> > > error = ENODEV; /* only mmap vnodes! */
> > > @@ -313,6 +316,7 @@ sys_mmap(struct proc *p, void *v, regist
> > > flags |= MAP_ANON;
> > > FRELE(fp, p);
> > > fp = NULL;
> > > + KERNEL_UNLOCK();
> > > goto is_anon;
> > > }
> > >
> > > @@ -362,9 +366,7 @@ sys_mmap(struct proc *p, void *v, regist
> > >* EPERM.
> > >*/
> > > if (fp->f_flag & FWRITE) {
> > > - KERNEL_LOCK();
> > > error = VOP_GETATTR(vp, , p->p_ucred, p);
> > > - KERNEL_UNLOCK();
> > > if (error)
> > > goto out;
> > > if ((va.va_flags & (IMMUTABLE|APPEND)) == 0)
> > > @@ -390,9 +392,9 @@ sys_mmap(struct proc *p, void *v, regist
> > > goto out;
> > > }
> > > }
> > > - KERNEL_LOCK();
> > > error = uvm_mmapfile(>p_vmspace->vm_map, , size, prot,
> > > maxprot, flags, vp, pos, lim_cur(RLIMIT_MEMLOCK), p);
> > > + FRELE(fp, p);
> > > KERNEL_UNLOCK();
> > > } else {/* MAP_ANON case */
> > > if (fd != -1)
> > > @@ -428,7 +430,10 @@ is_anon: /* label for SunOS style /dev/z
> > > /* remember to add offset */
> > > *retval = (register_t)(addr + pageoff);
> > >
> > > + return (error);
> > > +
> > > out:
> > > + KERNEL_UNLOCK();
> > > if (fp)
> > > FRELE(fp, p);
> > > return (error);
> > >
> > >
>
Re: fix: ospf6d(8): wrong intra area announcement
On Fri, Oct 02, 2020 at 02:01:09AM +0200, Jan Klemkow wrote:
> Hi,
>
> The new intra area db entry has to be saved into the tree before
> orig_intra_area_prefix_lsas() is called. If not, the ospf6d will not
> announce the new intra area db for a newly learned link from another
> ospf router of the broadcast domain.
>
> This bug is triggered, if you add new addresses an ospf interface while
> the ospf6d is already running as a backup designated router. The
> opposite designated ospf6d will get your new link announcement and
> return an old intra area db without the new address.
>
> Beside of the fix, the diff removes redundant code. I made the same
> diff for the ospfd to keep code in sync and remove redundant code there,
> too. ospfd does not have the bug explained above, as far as I know.
>
> Both regression tests passes with this diff.
>
> OK?
>
OK denis@ for ospf6d (it reverses a change a made).
> Bye,
> Jan
>
> Index: ospf6d/rde_lsdb.c
> ===
> RCS file: /cvs//src/usr.sbin/ospf6d/rde_lsdb.c,v
> retrieving revision 1.45
> diff -u -p -r1.45 rde_lsdb.c
> --- ospf6d/rde_lsdb.c 21 Aug 2020 10:17:35 - 1.45
> +++ ospf6d/rde_lsdb.c 1 Oct 2020 23:09:38 -
> @@ -467,6 +467,7 @@ lsa_add(struct rde_nbr *nbr, struct lsa
> struct lsa_tree *tree;
> struct vertex *new, *old;
> struct timeval tv, now, res;
> + int update = 1;
>
> if (LSA_IS_SCOPE_AS(ntohs(lsa->hdr.type)))
> tree = _tree;
> @@ -495,16 +496,13 @@ lsa_add(struct rde_nbr *nbr, struct lsa
> fatal("lsa_add");
> return (1);
> }
> - if (!lsa_equal(new->lsa, old->lsa)) {
> - if (ntohs(lsa->hdr.type) == LSA_TYPE_LINK)
> - orig_intra_area_prefix_lsas(nbr->area);
> - if (ntohs(lsa->hdr.type) != LSA_TYPE_EXTERNAL)
> - nbr->area->dirty = 1;
> - start_spf_timer();
> - }
> + if (lsa_equal(new->lsa, old->lsa))
> + update = 0;
> vertex_free(old);
> RB_INSERT(lsa_tree, tree, new);
> - } else {
> + }
> +
> + if (update) {
> if (ntohs(lsa->hdr.type) == LSA_TYPE_LINK)
> orig_intra_area_prefix_lsas(nbr->area);
> if (ntohs(lsa->hdr.type) != LSA_TYPE_EXTERNAL)
> Index: ospfd/rde_lsdb.c
> ===
> RCS file: /cvs//src/usr.sbin/ospfd/rde_lsdb.c,v
> retrieving revision 1.50
> diff -u -p -r1.50 rde_lsdb.c
> --- ospfd/rde_lsdb.c 22 Nov 2015 13:09:10 - 1.50
> +++ ospfd/rde_lsdb.c 1 Oct 2020 23:06:57 -
> @@ -383,6 +383,7 @@ lsa_add(struct rde_nbr *nbr, struct lsa
> struct lsa_tree *tree;
> struct vertex *new, *old;
> struct timeval tv, now, res;
> + int update = 1;
>
> if (lsa->hdr.type == LSA_TYPE_EXTERNAL ||
> lsa->hdr.type == LSA_TYPE_AS_OPAQ)
> @@ -410,15 +411,13 @@ lsa_add(struct rde_nbr *nbr, struct lsa
> fatal("lsa_add");
> return (1);
> }
> - if (!lsa_equal(new->lsa, old->lsa)) {
> - if (lsa->hdr.type != LSA_TYPE_EXTERNAL &&
> - lsa->hdr.type != LSA_TYPE_AS_OPAQ)
> - nbr->area->dirty = 1;
> - start_spf_timer();
> - }
> + if (lsa_equal(new->lsa, old->lsa))
> + update = 0;
> vertex_free(old);
> RB_INSERT(lsa_tree, tree, new);
> - } else {
> + }
> +
> + if (update) {
> if (lsa->hdr.type != LSA_TYPE_EXTERNAL &&
> lsa->hdr.type != LSA_TYPE_AS_OPAQ)
> nbr->area->dirty = 1;
>
pthread_spin_unlock and ownership behaviour
Back in 2012 kurt@ added an abort call for the undefined behaviour cases on pthread_mutex_unlock. This helped me a great deal in examining the cause of some weird behaviour in icinga (or in the case of openbsd, just plain crash). For shits and giggles I deceided to look into pthread_spin_unlock and saw that we return EPERM here, while POSIX states that this behaviour is unconditionally undefined.[0] Is there a reason why we shouldn't abort here as well? I don't have a particular usecase for this, but the mutex case helped me and it only seems like the right thing to do from a semetrical point of view. The only cases of pthread_spin_unlock in base I found were in libunbound (which with my testing with unwind didn't caused any issues) and gnu/llvm/compiler-rt/lib/tsan, which I don't know where to test. I have no idea which ports use it. martijn@ [0] https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_spin_unlock.html Index: librthread/rthread_spin_lock.c === RCS file: /cvs/src/lib/librthread/rthread_spin_lock.c,v retrieving revision 1.5 diff -u -p -r1.5 rthread_spin_lock.c --- librthread/rthread_spin_lock.c 6 Apr 2020 00:01:08 - 1.5 +++ librthread/rthread_spin_lock.c 3 Oct 2020 09:42:21 - @@ -102,12 +102,12 @@ pthread_spin_unlock(pthread_spinlock_t * pthread_spinlock_t l; if (lock == NULL || *lock == NULL) - return (EINVAL); + abort(); l = *lock; if (l->owner != self) - return (EPERM); + abort(); l->owner = NULL; _spinunlock(>lock); Index: libpthread/man/pthread_spin_unlock.3 === RCS file: /cvs/src/lib/libpthread/man/pthread_spin_unlock.3,v retrieving revision 1.3 diff -u -p -r1.3 pthread_spin_unlock.3 --- libpthread/man/pthread_spin_unlock.36 Apr 2020 00:01:08 - 1.3 +++ libpthread/man/pthread_spin_unlock.33 Oct 2020 09:42:21 - @@ -38,17 +38,14 @@ functions. .Sh RETURN VALUES If successful, .Fn pthread_spin_unlock -returns zero; otherwise an error number is returned to indicate the error. +returns zero. .Sh ERRORS .Fn pthread_spin_unlock -will fail if: -.Bl -tag -width Er -.It Bq Er EINVAL -The value specified by +will call +.Xr abort 3 +if the value specified by .Fa lock -is invalid. -.It Bq Er EPERM -The lock is not owned by the calling thread. +is invalid or if the lock is not owned by the calling thread. .El .Sh SEE ALSO .Xr pthread_spin_init 3 ,
new: rp(4): RocketPort multi serial port pci card driver
Hi,
The following diff contains a port of the FreeBSD driver for RocketPort PCI
cards. The tty interface works with getty(8) and the cua part with cu for
outbound connections. Some issues are still in, which I could not figure out
yet. I worked on this driver for one and half year now, and think it ready to
get in.
I've done a lot of clean up of the original FreeBSD code. Because there is no
specification available, I kept most of the comments. I also switched the
original polling mode, which is used in the FreeBSD and Linux version of the
driver to an interrupt driven mode.
This is my first major work in the driver section. I'm sure that I may miss
something. So, even nitpicks are welcome :-)
OK?
Thanks,
Jan
Index: share/man/man4/rp.4
===
RCS file: share/man/man4/rp.4
diff -N share/man/man4/rp.4
--- /dev/null 1 Jan 1970 00:00:00 -
+++ share/man/man4/rp.4 2 Oct 2020 17:50:01 -
@@ -0,0 +1,54 @@
+.\" $OpenBSD$
+.\"
+.\" Copyright (c) 2020 Jan Klemkow
+.\"
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies.
+.\"
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+.\"
+.Dd $Mdocdate: October 3 2020 $
+.Dt RP 4
+.Os
+.Sh NAME
+.Nm rp
+.Nd Comtrol RocketPort Intelligent Serial Port Cards device driver
+.Sh SYNOPSIS
+.Cd "rp* at pci?"
+.Sh DESCRIPTION
+This driver provides an interface to RocketPort multiport serial boards.
+.Pp
+The device minor numbers for this driver are encoded as follows:
+.Bd -literal
+d c c u u u u u- bits in the minor device number
+
+bitsmeaning
+---
+u physical serial line (i.e., unit) to use
+ 0-7 on a 8Y, 0-15 on a 16Y
+
+cc card number
+
+d dial-out flag
+.Ed
+.Sh SEE ALSO
+.Xr com 4 ,
+.Xr cy 4 ,
+.Xr intro 4 ,
+.Xr pci 4 ,
+.Xr termios 4 ,
+.Xr tty 4
+.Sh AUTHORS
+This driver was written under contract for Comtrol Corporation by
+.An Theodore Ts'o Aq Mt ty...@mit.edu .
+It was ported to OpenBSD by
+.An Jan Klemkow Aq Mt j.klem...@wemelug.de .
+.Sh BUGS
+Modem control does not work properly.
Index: sys/arch/amd64/amd64/conf.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/conf.c,v
retrieving revision 1.71
diff -u -p -r1.71 conf.c
--- sys/arch/amd64/amd64/conf.c 6 Jul 2020 04:32:25 - 1.71
+++ sys/arch/amd64/amd64/conf.c 2 Oct 2020 17:08:36 -
@@ -75,6 +75,12 @@ struct bdevswbdevsw[] =
};
intnblkdev = nitems(bdevsw);
+/* open, close, read, write, ioctl, tty, mmap */
+#define cdev_pc_init(c,n) { \
+ dev_init(c,n,open), dev_init(c,n,close), dev_init(c,n,read), \
+ dev_init(c,n,write), dev_init(c,n,ioctl), dev_init(c,n,stop), \
+ dev_init(c,n,tty), ttselect, dev_init(c,n,mmap), D_TTY }
+
/* open, close, read, ioctl */
#define cdev_joy_init(c,n) { \
dev_init(c,n,open), dev_init(c,n,close), dev_init(c,n,read), \
@@ -132,6 +138,8 @@ cdev_decl(lms);
#include "opms.h"
cdev_decl(pms);
#endif
+#include "rp.h"
+cdev_decl(rp);
#include "cy.h"
cdev_decl(cy);
#include "tun.h"
@@ -222,7 +230,7 @@ struct cdevsw cdevsw[] =
cdev_notdef(), /* 31 */
cdev_notdef(), /* 32 */
cdev_notdef(), /* 33 */
- cdev_notdef(), /* 34 */
+ cdev_tty_init(NRP,rp), /* 34: Comtrol RocketPort serial port */
cdev_notdef(), /* 35: Microsoft mouse */
cdev_notdef(), /* 36: Logitech mouse */
cdev_notdef(), /* 37: Extended PS/2 mouse */
Index: sys/arch/amd64/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v
retrieving revision 1.493
diff -u -p -r1.493 GENERIC
--- sys/arch/amd64/conf/GENERIC 15 Sep 2020 18:31:14 - 1.493
+++ sys/arch/amd64/conf/GENERIC 2 Oct 2020 17:08:39 -
@@ -399,6 +399,7 @@ com*at puc?
# options CY_HW_RTS
#cy* at pci? # PCI cyclom serial card
#cz* at pci? # Cyclades-Z multi-port serial boards
+rp*at pci? # PCI RocketPort serial card
lpt0 at isa? port 0x378 irq 7# standard PC parallel ports
#lpt1 at isa? port 0x278
Re: Please test: switch select(2) to kqfilters
On 02/10/20(Fri) 19:09, Scott Cheloha wrote:
> On Fri, Oct 02, 2020 at 12:19:35PM +0200, Martin Pieuchot wrote:
> > @@ -635,12 +642,39 @@ sys_kevent(struct proc *p, void *v, regi
> > goto done;
> > }
> >
> > +
> > KQREF(kq);
> > FRELE(fp, p);
> > - error = kqueue_scan(kq, SCARG(uap, nevents), SCARG(uap, eventlist),
> > - tsp, kev, p, );
> > + /*
> > +* Collect as many events as we can. The timeout on successive
> > +* loops is disabled (kqueue_scan() becomes non-blocking).
> > +*/
> > + total = 0;
> > + error = 0;
> > + kqueue_scan_setup(, kq);
> > + while ((n = SCARG(uap, nevents) - total) > 0) {
> > + if (n > nitems(kev))
> > + n = nitems(kev);
> > + ready = kqueue_scan(, n, kev, tsp, p, );
> > + if (ready == 0)
> > + break;
> > + error = copyout(kev, SCARG(uap, eventlist) + total,
> > + sizeof(struct kevent) * ready);
> > +#ifdef KTRACE
> > + if (KTRPOINT(p, KTR_STRUCT))
> > + ktrevent(p, kev, ready);
> > +#endif
> > + total += ready;
> > + if (error || ready < n)
> > + break;
> > + tsp = /* successive loops non-blocking */
> > + timespecclear(tsp);
>
> Here, this. Why do we force a non-blocking loop the second time?
If there's a second time that implies the first time already reported
some events so there's already something to return to userland. In that
case we just want to gather the events that were not collected the first
time and not sleep again.
> > + }
> > + kqueue_scan_finish();
> > KQRELE(kq);
> > - *retval = n;
> > + if (error == EWOULDBLOCK)
> > + error = 0;
> > + *retval = total;
> > return (error);
> >
> > done:
> > @@ -894,24 +928,22 @@ kqueue_sleep(struct kqueue *kq, struct t
> > return (error);
> > }
> >
> > +/*
> > + * Scan the kqueue, blocking if necessary until the target time is reached.
> > + * If tsp is NULL we block indefinitely. If tsp->ts_secs/nsecs are both
> > + * 0 we do not block at all.
> > + */
> > int
> > -kqueue_scan(struct kqueue *kq, int maxevents, struct kevent *ulistp,
> > -struct timespec *tsp, struct kevent *kev, struct proc *p, int *retval)
> > +kqueue_scan(struct kqueue_scan_state *scan, int maxevents,
> > +struct kevent *kevp, struct timespec *tsp, struct proc *p, int *errorp)
> > {
> > - struct kevent *kevp;
> > - struct knote mend, mstart, *kn;
> > - int s, count, nkev, error = 0;
> > -
> > - nkev = 0;
> > - kevp = kev;
> > + struct knote *kn;
> > + struct kqueue *kq = scan->kqs_kq;
> > + int s, count, nkev = 0, error = 0;
> >
> > count = maxevents;
> > if (count == 0)
> > goto done;
> > -
> > - memset(, 0, sizeof(mstart));
> > - memset(, 0, sizeof(mend));
> > -
> > retry:
> > KASSERT(count == maxevents);
> > KASSERT(nkev == 0);
> > @@ -923,7 +955,8 @@ retry:
> >
> > s = splhigh();
> > if (kq->kq_count == 0) {
> > - if (tsp != NULL && !timespecisset(tsp)) {
> > + if ((tsp != NULL && !timespecisset(tsp)) ||
> > + scan->kqs_nevent != 0) {
> > splx(s);
> > error = 0;
> > goto done;
> > @@ -931,7 +964,7 @@ retry:
> > kq->kq_state |= KQ_SLEEP;
> > error = kqueue_sleep(kq, tsp);
> > splx(s);
> > - if (error == 0 || error == EWOULDBLOCK)
> > + if (error == 0)
> > goto retry;
>
> Why wouldn't we want to retry in the EWOULDBLOCK case?
> You have a check for
>
> tsp != NULL && !timespecisset(tsp)
>
> e.g., when you time out.
I don't recall why or even if there was a reason. I'll change it back,
thanks.
> > +
> > + /*
> > +* The poll/select family of syscalls has been designed to
> > +* block when file descriptors are not available, even if
> > +* there's nothing to wait for.
> > +*/
> > + if (nevents == 0) {
> > + uint64_t nsecs = INFSLP;
> > +
> > + if (timeout != NULL)
> > + nsecs = MAX(1, MIN(TIMESPEC_TO_NSEC(timeout), MAXTSLP));
> > +
> > + error = tsleep_nsec(>p_kq, PSOCK | PCATCH, "kqsel", nsecs);
> > + /* select is not restarted after signals... */
> > + if (error == ERESTART)
> > + error = EINTR;
> > + }
>
> Aside: can the new logic (below) not handle the case where
> nevents == 0? Like, what happens if we go into kqueue_scan()
> with count == 0?
First like of kqueue_scan() does:
if (count == 0)
goto done
So there's no sleep. I opted for the explicit sleep rather than the
obfuscated one ;)
> > + /* Collect at most `nevents' possibly waiting in kqueue_scan() */
> > + kqueue_scan_setup(, p->p_kq);
> > + while (nevents > 0) {
> > + struct kevent
Re: Make df output more human friendly in daily(8)
Hi Daniel, my OK still stands, except that you went too far in one respect in the manual page, see below. Yours, Ingo Daniel Jakots wrote on Fri, Oct 02, 2020 at 03:41:31PM -0400: > Index: share/man/man8/daily.8 > === > RCS file: /cvs/src/share/man/man8/daily.8,v > retrieving revision 1.28 > diff -u -p -r1.28 daily.8 > --- share/man/man8/daily.826 Jul 2020 13:27:24 - 1.28 > +++ share/man/man8/daily.82 Oct 2020 19:34:47 - > @@ -114,15 +114,6 @@ Lists any daemons which are enabled in > .Xr rc.conf.local 8 > but which are not actually running. > .It > -Checks disk status. > -Reports on the amount of disk used/available via > -.Xr df 1 . So far, so good. But this needs to remain: > -Reports on which file systems need to be dumped via > -.Xr dump 8 . > -.It >From here on, deletion is OK again. > -Reports networking statistics via > -.Xr netstat 1 . > -.It > Runs the > .Xr calendar 1 > utility unless the environment variable > @@ -205,15 +196,6 @@ If set to 1, run > with the no-write flag. > .It Ev ROOTBACKUP > If set to 1, make a backup of the root file system. > -.It Ev VERBOSESTATUS > -If set to 0, > -.Xr df 1 , > -.Xr dump 8 , > -and > -.Xr netstat 1 > -are skipped. > -Consequently, if none of the other commands produce any output, > -no mail will be sent to root. > .El > .Pp > The following variables can be set in > @@ -250,9 +232,7 @@ Root > .Sh SEE ALSO > .Xr calendar 1 , > .Xr crontab 1 , > -.Xr df 1 , > .Xr locate 1 , > -.Xr netstat 1 , > .Xr rdist 1 , > .Xr whatis 1 , > .Xr crontab 5 ,
