simultaneous sound as many users
My sndio configuration is default, OBSD 5.9. When I run a media file in e.g. mpv, and pause it without closing, and try to listen to smth in chrome _as another user_, there is no sound: [12530:2084997376:0402/012418:ERROR:sndio_output.cc(65)] Couldn't open audio device. Reverse is true, if I listened to anything in chrome first, mpv as another user fails to play audio: (+) Video --vid=1 (mpeg4) (+) Audio --aid=1 (ac3) [ao/sndio] can't open sndio default [ao] Failed to initialize audio driver 'sndio' Could not open/initialize audio device -> no sound. Audio: no audio Doing this as a same user works, but is there a way to do it as many users at once?
Re: Crash after updating to today's snapshot
On Sat, Apr 02, 2016 at 12:24:13AM -0400, Luke Tidd wrote: > Machine is a Thinkpad x230. First crash after an update. Thanks for the report. Pleasae report bugs to the bugs@ mailing list because not everybody reads misc@. The change that led to this has been reverted: https://marc.info/?l=openbsd-bugs&m=145954247112249&w=2
Re: Crash after updating to today's snapshot
The change responsible for that has already been reverted http://marc.info/?l=openbsd-cvs&m=145951161601747&w=2 Snapshots dated after that time should be fine. On Sat, Apr 02, 2016 at 12:24:13AM -0400, Luke Tidd wrote: > Machine is a Thinkpad x230. First crash after an update. > > -- > dmesg from bsd.rd: > > OpenBSD 5.9-current (GENERIC) #1849: Thu Mar 31 14:46:38 MDT 2016 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC > real mem = 16845570048 (16065MB) > avail mem = 16330719232 (15574MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9d000 (68 entries) > bios0: vendor LENOVO version "G7ET94WW (2.54 )" date 04/30/2013 > bios0: LENOVO 2356CP4 > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT > FPDT ASF! UEFI UEFI POAT SSDT SSDT DMAR UEFI DBG2 > acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3) > EHC1(S3) EHC2(S3) HDEF(S4) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpihpet0 at acpi0: 14318179 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz, 2594.50 MHz > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS > H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX > ,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,A > ES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,AR > AT > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE > cpu at mainbus0: not configured > cpu at mainbus0: not configured > cpu at mainbus0: not configured > ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins > acpimcfg0 at acpi0 addr 0xf800, bus 0-63 > acpiec0 at acpi0 > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus -1 (PEG_) > acpiprt2 at acpi0: bus 2 (EXP1) > acpiprt3 at acpi0: bus 3 (EXP2) > acpiprt4 at acpi0: bus 4 (EXP3) > acpiprt5 at acpi0: bus -1 (EXP5) > acpiprt6 at acpi0: bus -1 (EXP6) > acpiprt7 at acpi0: bus -1 (EXP7) > acpiprt8 at acpi0: bus -1 (EXP8) > acpicpu0 at acpi0: C2(350@80 mwait.1@0x20), C1(1000@1 mwait.1), PSS > acpipwrres0 at acpi0: PUBS, resource for XHCI, EHC1, EHC2 > acpitz0 at acpi0: critical temperature is 103 degC > "PNP0C0F" at acpi0 not configured > "PNP0C0F" at acpi0 not configured > "PNP0C0F" at acpi0 not configured > "PNP0C0F" at acpi0 not configured > "PNP0C0F" at acpi0 not configured > "PNP0C0F" at acpi0 not configured > "PNP0C0F" at acpi0 not configured > "PNP0C0F" at acpi0 not configured > "PNP0C01" at acpi0 not configured > acpibtn0 at acpi0: LID_ > acpibtn1 at acpi0: SLPB > "PNP0A08" at acpi0 not configured > "PNP0C02" at acpi0 not configured > "PNP" at acpi0 not configured > "PNP0100" at acpi0 not configured > "PNP0103" at acpi0 not configured > "PNP0200" at acpi0 not configured > "PNP0800" at acpi0 not configured > "PNP0C04" at acpi0 not configured > "PNP0B00" at acpi0 not configured > "LEN0071" at acpi0 not configured > "LEN0015" at acpi0 not configured > "SMO1200" at acpi0 not configured > "PNP0C09" at acpi0 not configured > acpibat0 at acpi0: BAT0 model "45N1037" serial 4763 type LION oem "SANYO" > acpibat1 at acpi0: BAT1 model "45N1041" serial 2371 type LiP oem "SONY" > acpiac0 at acpi0: AC unit online > "LEN0078" at acpi0 not configured > acpithinkpad0 at acpi0 > "PNP0C14" at acpi0 not configured > "PNP0C14" at acpi0 not configured > acpivideo0 at acpi0: VID_ > acpivout at acpivideo0 not configured > acpivideo1 at acpi0: VID_ > cpu0: Enhanced SpeedStep 2594 MHz: speeds: 2601, 2600, 2500, 2400, > 2300, 2200, 2100, 2000, 1900, 1800, 1700, 1600, 1500, 1400, 1300, 1200 > MHz > pci0 at mainbus0 bus 0 > pchb0 at pci0 dev 0 function 0 "Intel Core 3G Host" rev 0x09 > inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 4000" rev 0x09 > drm0 at inteldrm0 > inteldrm0: msi > inteldrm0: 1600x900 > wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation) > wsdisplay0: screen 1-5 added (std, vt100 emulation) > xhci0 at pci0 dev 20 function 0 "Intel 7 Series xHCI" rev 0x04: msi > usb0 at xhci0: USB revision 3.0 > uhub0 at usb0 "Intel xHCI root hub" rev 3.00/1.00 addr 1 > "Intel 7 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured > puc0 at pci0 dev 22 function 3 "Intel 7 Series KT" rev 0x04: ports: 1 com > com4 at puc0 port 0 apic 2 int 19: ns16550a, 16 byte fifo > com4: probed fifo depth: 0 bytes > em0 at pci0 dev 25 function 0 "Intel 82579LM" rev 0x04: msi, address > 3c:97:0e:ab:e0:49 > ehci0 at pci0 dev 26 function 0 "Intel 7 Series USB" rev 0x04: apic 2 int 16 > usb1 at ehci0: USB revision 2.0 > uhub1 at usb1 "Intel EHCI root hub" rev 2.00/1.00 addr
Re: Crash after updating to today's snapshot
On Fri, Apr 1, 2016 at 9:24 PM, Luke Tidd wrote: > Machine is a Thinkpad x230. First crash after an update. ... > Fri Apr 1 22:06:05 EDT 2016 > uvm_fault(0xff041c9df100, 0x0, 0, 1) -> e > kernel: page fault trap, code=0 > Stopped at spec_open_clone+0x80: movzbl 0 (%rdi),%edx > ddb{0}> machine ddbcpu 0 Problem commit has been backed out already; next snapshot should work. Philip Guenther
Crash after updating to today's snapshot
Machine is a Thinkpad x230. First crash after an update. -- dmesg from bsd.rd: OpenBSD 5.9-current (GENERIC) #1849: Thu Mar 31 14:46:38 MDT 2016 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC real mem = 16845570048 (16065MB) avail mem = 16330719232 (15574MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9d000 (68 entries) bios0: vendor LENOVO version "G7ET94WW (2.54 )" date 04/30/2013 bios0: LENOVO 2356CP4 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT ASF! UEFI UEFI POAT SSDT SSDT DMAR UEFI DBG2 acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz, 2594.50 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,A ES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,AR AT cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiec0 at acpi0 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP1) acpiprt3 at acpi0: bus 3 (EXP2) acpiprt4 at acpi0: bus 4 (EXP3) acpiprt5 at acpi0: bus -1 (EXP5) acpiprt6 at acpi0: bus -1 (EXP6) acpiprt7 at acpi0: bus -1 (EXP7) acpiprt8 at acpi0: bus -1 (EXP8) acpicpu0 at acpi0: C2(350@80 mwait.1@0x20), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: PUBS, resource for XHCI, EHC1, EHC2 acpitz0 at acpi0: critical temperature is 103 degC "PNP0C0F" at acpi0 not configured "PNP0C0F" at acpi0 not configured "PNP0C0F" at acpi0 not configured "PNP0C0F" at acpi0 not configured "PNP0C0F" at acpi0 not configured "PNP0C0F" at acpi0 not configured "PNP0C0F" at acpi0 not configured "PNP0C0F" at acpi0 not configured "PNP0C01" at acpi0 not configured acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB "PNP0A08" at acpi0 not configured "PNP0C02" at acpi0 not configured "PNP" at acpi0 not configured "PNP0100" at acpi0 not configured "PNP0103" at acpi0 not configured "PNP0200" at acpi0 not configured "PNP0800" at acpi0 not configured "PNP0C04" at acpi0 not configured "PNP0B00" at acpi0 not configured "LEN0071" at acpi0 not configured "LEN0015" at acpi0 not configured "SMO1200" at acpi0 not configured "PNP0C09" at acpi0 not configured acpibat0 at acpi0: BAT0 model "45N1037" serial 4763 type LION oem "SANYO" acpibat1 at acpi0: BAT1 model "45N1041" serial 2371 type LiP oem "SONY" acpiac0 at acpi0: AC unit online "LEN0078" at acpi0 not configured acpithinkpad0 at acpi0 "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured acpivideo0 at acpi0: VID_ acpivout at acpivideo0 not configured acpivideo1 at acpi0: VID_ cpu0: Enhanced SpeedStep 2594 MHz: speeds: 2601, 2600, 2500, 2400, 2300, 2200, 2100, 2000, 1900, 1800, 1700, 1600, 1500, 1400, 1300, 1200 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 3G Host" rev 0x09 inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 4000" rev 0x09 drm0 at inteldrm0 inteldrm0: msi inteldrm0: 1600x900 wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) xhci0 at pci0 dev 20 function 0 "Intel 7 Series xHCI" rev 0x04: msi usb0 at xhci0: USB revision 3.0 uhub0 at usb0 "Intel xHCI root hub" rev 3.00/1.00 addr 1 "Intel 7 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured puc0 at pci0 dev 22 function 3 "Intel 7 Series KT" rev 0x04: ports: 1 com com4 at puc0 port 0 apic 2 int 19: ns16550a, 16 byte fifo com4: probed fifo depth: 0 bytes em0 at pci0 dev 25 function 0 "Intel 82579LM" rev 0x04: msi, address 3c:97:0e:ab:e0:49 ehci0 at pci0 dev 26 function 0 "Intel 7 Series USB" rev 0x04: apic 2 int 16 usb1 at ehci0: USB revision 2.0 uhub1 at usb1 "Intel EHCI root hub" rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 "Intel 7 Series HD Audio" rev 0x04: msi azalia0: codecs: Realtek ALC269, Intel/0x2806, using Realtek ALC269 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 "Intel 7 Series PCIE" rev 0xc4: msi pci1 at ppb0 bus 2 ppb1 at pci0 dev 28 function 1 "Intel 7 Series PCIE" rev 0xc4: msi pci2 at ppb1 bus 3 iwn0 at pci2 dev 0 function 0 "Intel Centrino Ultimate-N 6300" rev 0x3e: msi, MIMO 3T3R, MoW, address 3c:a9:f4
2016-MAR-30 amd64 snapshot won't wake from sleep
Hi, Just upgraded my laptop/netbook to 2016-MAR-30 amd64 snapshot. I build a few ports, things seemed fine. Made it sleep by shutting the lid. Trying to wake it up by opening lid, pressing a key (e.g., space-bar) as it used to work previously by waking up the machine. However, with this snapshot, it seems like it is tries to wake up -- screen lights up for a second, but then the speaker chirps, and it goes back to sleep. Pressing the button (or another button) repeats the screen light-up, chirp and sleep cycle over again. Is there anything I should try (or rather a dev would like me to try) before I force reboot it to get you a dmesg? Thanks, --patrick
Re: doas.conf cmd with argument(s)
On Fri, Apr 01, 2016 at 02:47:42PM -0700, Philip Guenther wrote: [snip] > Sooo close. To quote doas.conf(5): > [snip] > 'args' is *literal* there, so the correct config line would be > permit nopass support as root cmd /usr/sbin/rcctl args restart ntpd > Hahaha, holy fballs! *donk* (I'll blame the hour. Yes, I think I will.)) Thanks! Tor PS: Here's a diff :-) --- /usr/share/man/man5/doas.conf.5 Fri Feb 26 09:08:04 2016 +++ doas.conf.5 Sat Apr 2 00:14:34 2016 @@ -129,6 +129,7 @@ SUBPACKAGE WRKOBJDIR SUDO_PORT_V1 } :wsrc permit nopass keepenv { ENV PS1 SSH_AUTH_SOCK } :wheel permit nopass tedu as root cmd /usr/sbin/procmap +permit nopass tedu as root cmd /usr/sbin/rcctl args restart ntpd permit nopass keepenv root as root .Ed .Sh SEE ALSO
Re: doas.conf cmd with argument(s)
see doas.conf(5): args ... Arguments to command. If specified, the command arguments provided by the user need to match for the command to be successful. Specifying args alone means that command should be run without any arguments. You forgot the args keyword. On 04/01/16 23:33, Tor Houghton wrote: > Hi, > > Now that sudo is out of base, I am wondering -- do I need to add it again, > or does doas.conf allow for specifying commands with arguments? > > Obviously not like this (doas doesn't like that), but akin to: > > permit nopass support as root cmd /usr/sbin/rcctl restart ntpd > > I don't want the support user to be able to use rcctl on any daemon process, > basically. > > Kind regards, > > Tor
Re: doas.conf cmd with argument(s)
On Fri, Apr 1, 2016 at 2:33 PM, Tor Houghton wrote: > Now that sudo is out of base, I am wondering -- do I need to add it again, > or does doas.conf allow for specifying commands with arguments? > > Obviously not like this (doas doesn't like that), but akin to: > > permit nopass support as root cmd /usr/sbin/rcctl restart ntpd > > I don't want the support user to be able to use rcctl on any daemon process, > basically. Sooo close. To quote doas.conf(5): The rules have the following format: permit|deny [options] identity [as target] [cmd command [args ...]] ... cmd command The command the user is allowed or denied to run. The default is all commands. Be advised that it's best to specify absolute paths. If a cmd is specified, only a restricted PATH will be searched. args ... Arguments to command. If specified, the command arguments provided by the user need to match for the command to be successful. Specifying args alone means that command should be run without any arguments. 'args' is *literal* there, so the correct config line would be permit nopass support as root cmd /usr/sbin/rcctl args restart ntpd Philip Guenther
doas.conf cmd with argument(s)
Hi, Now that sudo is out of base, I am wondering -- do I need to add it again, or does doas.conf allow for specifying commands with arguments? Obviously not like this (doas doesn't like that), but akin to: permit nopass support as root cmd /usr/sbin/rcctl restart ntpd I don't want the support user to be able to use rcctl on any daemon process, basically. Kind regards, Tor
Re: WAPBL?
Nope, my cvs tree is clean. i only applied those diffs since they are small. On Fri, Apr 1, 2016 at 10:56 AM, Bob Beck wrote: > I would hazard a guess that if you are running a random diff, the > problem is with the diff you are running - not those other things. > > On Fri, Apr 1, 2016 at 9:30 AM, Amit Kulkarni wrote: > > I see the writes are not being done to disk in case of a simple cvs > update, > > and the machine locks up for a solid couple of minutes afterwards also. > This > > happens in a dual CPU config with plenty of free memory, even with > stefan, > > mpi and kettenis recent diffs. For a curious kernel reader, where could > the > > bug(s) be? in amap, uvm/buffer cache, rthreads??? > > > > Thanks in advance > > > > > > On Fri, Apr 1, 2016 at 9:06 AM, Bob Beck wrote: > >> > >> I have more up to date versions of these patches around here. > >> > >> The problem with them is that fundamentally, the WAPBL implementation > >> as it is assumes that it may infinitely steal > >> buffers from the buffer cache and hold onto them indefinitely - and it > >> assumes it can always get buffers from it. While the patch as it sits > >> may "work" in the "happy case" on many people's machines, as it sits > >> today it is dangerous and can lock up your machine and corrupt things > >> in low memory situations. > >> > >> Basically in order to progres WAPBL (renamed "FFS Journalling" here) > >> needs to have a mechanism added to allow > >> it be told "no it can't have a buffer" and let it deal with it > >> correctly. The first part is done, the latter part is complex. > >> > >> > >> On Sat, Mar 26, 2016 at 1:27 PM, Martijn Rijkeboer > >> wrote: > >> > Hi, > >> > > >> > Just out of curiosity, what has happend with WAPBL? There were some > >> > patches > >> > floating around on tech@ in the last months of 2015, but then it > became > >> > quiet. I'm not complaining just curious. > >> > > >> > Kind regards, > >> > > >> > > >> > Martijn Rijkeboer
multiple interfaces on same subnet and routing
Hello All, Unless I have made a significant mistake in interpreting the diagnostic steps, if an OpenBSD host/server has multiple interfaces that are connected to the same subnet, it is not guaranteed that inbound traffic to one of those interfaces is replied to from the same interface on which the packets of the flow were received. This was surprising and non-obvious behavior to me. Is there some documentation I may have missed which discusses this point? More importantly, is there a way to achieve the behavior I was expecting to see, which is if traffic is received on one interface of multiple connected to a subnet, that replies to that traffic come from the same interface? I was able to use priorities in hostname.if , but this establishes which is the statically preferred interface rather than ensuring reply traffic goes out the interface it arrived on. I tried reply-to in pf.conf , and it neither accomplished this nor do I think it is the use case that was intended. If it matters, the following is my use-case. I am trying to solve the issue of bidirectional queueing with multiple internal subnets, as per #1 in: http://marc.info/?l=openbsd-misc&m=145684624301015&w=2 The only workable approach I could find was to tie all the internal interfaces and a vether if together into a bridge, and treat the vether as the $int_if. Since IP addresses are to be assigned to the internal hosts via DHCP, and since dhcpd doesn't filter by tags inserted by bridge rules, the only way to have dhcpd assign the intended addresses by subnet was to have a distinct interface for each subnet. Now if I deliberately want to send traffic to the distinct interfaces for DHCP, it gets passed in just fine, but the reply traffic seems to come from the $int_if vether that is connected to the bridge with all the aliases to support being a gateway from all subnets. Thanks for any insight.
Re: WAPBL?
I would hazard a guess that if you are running a random diff, the problem is with the diff you are running - not those other things. On Fri, Apr 1, 2016 at 9:30 AM, Amit Kulkarni wrote: > I see the writes are not being done to disk in case of a simple cvs update, > and the machine locks up for a solid couple of minutes afterwards also. This > happens in a dual CPU config with plenty of free memory, even with stefan, > mpi and kettenis recent diffs. For a curious kernel reader, where could the > bug(s) be? in amap, uvm/buffer cache, rthreads??? > > Thanks in advance > > > On Fri, Apr 1, 2016 at 9:06 AM, Bob Beck wrote: >> >> I have more up to date versions of these patches around here. >> >> The problem with them is that fundamentally, the WAPBL implementation >> as it is assumes that it may infinitely steal >> buffers from the buffer cache and hold onto them indefinitely - and it >> assumes it can always get buffers from it. While the patch as it sits >> may "work" in the "happy case" on many people's machines, as it sits >> today it is dangerous and can lock up your machine and corrupt things >> in low memory situations. >> >> Basically in order to progres WAPBL (renamed "FFS Journalling" here) >> needs to have a mechanism added to allow >> it be told "no it can't have a buffer" and let it deal with it >> correctly. The first part is done, the latter part is complex. >> >> >> On Sat, Mar 26, 2016 at 1:27 PM, Martijn Rijkeboer >> wrote: >> > Hi, >> > >> > Just out of curiosity, what has happend with WAPBL? There were some >> > patches >> > floating around on tech@ in the last months of 2015, but then it became >> > quiet. I'm not complaining just curious. >> > >> > Kind regards, >> > >> > >> > Martijn Rijkeboer
Re: OT: True hardware UNIX terminal
Steve Litt wrote: > I was a DEC PDP/11 TSX over RT-11 guy back then, but as I remember, a > terminal was a television that printed letters and numbers plus a > keyboard on which you could type. I have to disagree a little bit in that actual TVs were too low-rez for good 80-column text, which has a longer tradition. However, TV-compatible 40-column or lower text modes did come into play during the microcomputer revolution, at the Homebrew Computer Club, and with the TV Typewriter (which was more of an electronics hobbyist project, but could be turned into a terminal, though not a "professional" one). The DOS PC CGA also supported 40-column modes--it had a composite/TV output besides RGBI. Of course, if by television you basically meant CRT, then I'd agree. I'll add some more, actually. (This isn't first-hand knowledge, but I forget where I got it from -- possibly various sources.) Here's some -=PREHISTORY=- which explains more of how terminals came to be: The kind of early electronic data processing that lead to terminals really started with (electromechanical) tabulating machines. Those gave us the standardized punch card. Edwin Black's "IBM and the Holocaust" contains (not very detailed and technical) descriptions, and even photos of such a machine and some punch cards. An early use for these evolving machines was the census, in the US and later in (Nazi-) Germany. The way this worked was, these cardboard punch cards got holes stamped into them to encode information on them. This was done in dedicated card punches (keypunches: https://en.wikipedia.org/wiki/Keypunch), which generally were a cross between a hole punch and a typewriter. There was an array of rows and columns and a clerical worker would type and thereby punch the right holes in the right positions. IBM soon standardized on the 80-column card, and that's why most terminals, screen fidelity permitting, got 80-column text. One punch card could encode one such line of text. (ASCII text? Well, sort of, similar. Let's forget that EBCDIC ever existed.) https://en.wikipedia.org/wiki/Punched_card#IBM_80-column_punched_card_formats_and_character_codes I don't know if there's a specific reason for the 24 (later sometimes 25) lines of most terminals, but I guess it had to do with being a multiple of 8 and just how many 80-column lines could legibly be fit onto a 4:3 aspect ratio CRT display. But that came later. Back to the cards. Those punch cards were fed to a reader, which was an array of contacts that would be lowered onto and --holes permitting-- through a card. Early tabulators had little pockets of liquid mercury underneath each position, and the electrical circuit was closed by the contacts dipping into that. (Hello OSHA.) Those tabulating machines weren't computers, and some early ones just had clock dial counters, on which hands would advance when a contact was closed. This already allowed electromechanical addition though: Feed in a card, read it, have the hands advance. Feed in a second card, read it, have the hands advance some more. https://en.wikipedia.org/wiki/File:HollerithMachine.CHM.jpg Other tabulating machine setups included sorters, where cards would be sorted in different output stacks depending on their hole-encoded information. (There's a link from that to VisiCalc and Excel, but that's OT to this OT post.) When computers were invented, these 80-column cards quickly became the industry-standard input/output mechanism. https://en.wikipedia.org/wiki/Punched_card_input/output The programmer/user would write a program or calculation on paper, mail or hand that paper to the clerical staff who would type/punch that information into cards, and then a whole pile of punched cards would be delivered to the computer operators, who would carefully deposit them into the punch card reader, and these machines had feeders which could quickly process a whole batch of cards, one after another. This is what gave us batch processing. For output, these computers could either themselves punch cards and/or they could use a line printer. https://en.wikipedia.org/wiki/Line_printer (Sometimes the output was the way the cards got sorted, but that was mostly a tabulating machine thing.) It was pretty standard then to hand in your program sheets and get back your printed results back on continuous stationery. https://en.wikipedia.org/wiki/Continuous_stationery This was technically multi-user, but you had to queue and wait maybe hours or a day for your cards to be processed and to get your results back. Longer if it went through the mail. (DO NOT BEND was very important if punch cards were mailed, because punch card readers really don't like warped cards.) https://en.wikipedia.org/wiki/Time-sharing#Batch_processing Meanwhile, the telegraphy industry had developed the teletype, which was a teleprinter, basically a typewriter that could electronically transmit typed characters, across a room or across the country, and
Help with IPsec multiple transform configuration
Apologies if this was already sent, I am having difficulty with my email lately and this didn't look like it sent earlier. Good morning everyone, I am wondering is there a way to allow either via /etc/ipsec.conf or /etc/isakmpd/isakmpd.policy to configure a road warrior type of IPsec VPN access to my router that accomodates multiple types of IPsec clients that regrettably have limitations in the auth/enc/DH groups they support. For instance I am trying to get my IPsec/L2TP tunnel VPN working with two separate clients that support it, but have weird limitations. My Android phone only works when I set my ipsec.conf file to something like the following: ike passive esp transport \Â Â Â Â proto udp from XXX.XXX.XXX.XXX to any port 1701 \Â Â Â Â main auth "hmac-sha" enc "aes" group "modp1024" \Â Â Â Â quick auth "hmac-sha" enc "aes" group "modp1024" \Â Â Â Â psk "presharedkey" But that won't work with my Chromebook which requires: ike passive esp transport \Â Â Â Â proto udp from XXX.XXX.XXX.XXX to any port 1701 \Â Â Â Â main auth "hmac-md5" enc "aes" group "modp2048" \Â Â Â Â quick auth "hmac-md5" enc "aes" group "modp2048" \Â Â Â Â psk "presharedkey" One requires md5 but only with modp2048 while the other might work with md5, but only with modp1024. Â If I don't specify these options than neither work so I have to, but doing so seems to limit me to one or the other. Is there any way I can specify both versions simultaneously? Â I don't see anything in the various manpages about being able to allow multiple transforms. Any help would be greatly appreciated. Sly
Re: WAPBL?
I see the writes are not being done to disk in case of a simple cvs update, and the machine locks up for a solid couple of minutes afterwards also. This happens in a dual CPU config with plenty of free memory, even with stefan, mpi and kettenis recent diffs. For a curious kernel reader, where could the bug(s) be? in amap, uvm/buffer cache, rthreads??? Thanks in advance On Fri, Apr 1, 2016 at 9:06 AM, Bob Beck wrote: > I have more up to date versions of these patches around here. > > The problem with them is that fundamentally, the WAPBL implementation > as it is assumes that it may infinitely steal > buffers from the buffer cache and hold onto them indefinitely - and it > assumes it can always get buffers from it. While the patch as it sits > may "work" in the "happy case" on many people's machines, as it sits > today it is dangerous and can lock up your machine and corrupt things > in low memory situations. > > Basically in order to progres WAPBL (renamed "FFS Journalling" here) > needs to have a mechanism added to allow > it be told "no it can't have a buffer" and let it deal with it > correctly. The first part is done, the latter part is complex. > > > On Sat, Mar 26, 2016 at 1:27 PM, Martijn Rijkeboer > wrote: > > Hi, > > > > Just out of curiosity, what has happend with WAPBL? There were some > patches > > floating around on tech@ in the last months of 2015, but then it became > > quiet. I'm not complaining just curious. > > > > Kind regards, > > > > > > Martijn Rijkeboer
Help with IPsec multiple transform policy
Good morning everyone, I am wondering is there a way to allow either via /etc/ipsec.conf or /etc/isakmpd/isakmpd.policy to configure a road warrior type of IPsec VPN access to my router that accomodates multiple types of IPsec clients that regrettably have limitations in the auth/enc/DH groups they support. For instance I am trying to get my IPsec/L2TP tunnel VPN working with two separate clients that support it, but have weird limitations. My Android phone only works when I set my ipsec.conf file to something like the following: ike passive esp transport \Â Â Â Â proto udp from XXX.XXX.XXX.XXX to any port 1701 \Â Â Â Â main auth "hmac-sha" enc "aes" group "modp1024" \Â Â Â Â quick auth "hmac-sha" enc "aes" group "modp1024" \Â Â Â Â psk "presharedkey" But that won't work with my Chromebook which requires: ike passive esp transport \Â Â Â Â proto udp from XXX.XXX.XXX.XXX to any port 1701 \Â Â Â Â main auth "hmac-md5" enc "aes" group "modp2048" \Â Â Â Â quick auth "hmac-md5" enc "aes" group "modp2048" \Â Â Â Â psk "presharedkey" One requires md5 but only with modp2048 while the other might work with md5, but only with modp1024. Â If I don't specify these options than neither work so I have to, but doing so seems to limit me to one or the other. Is there any way I can specify both versions simultaneously? Â I don't see anything in the various manpages about being able to allow multiple transforms. Any help would be greatly appreciated. Sly
Re: WAPBL?
I have more up to date versions of these patches around here. The problem with them is that fundamentally, the WAPBL implementation as it is assumes that it may infinitely steal buffers from the buffer cache and hold onto them indefinitely - and it assumes it can always get buffers from it. While the patch as it sits may "work" in the "happy case" on many people's machines, as it sits today it is dangerous and can lock up your machine and corrupt things in low memory situations. Basically in order to progres WAPBL (renamed "FFS Journalling" here) needs to have a mechanism added to allow it be told "no it can't have a buffer" and let it deal with it correctly. The first part is done, the latter part is complex. On Sat, Mar 26, 2016 at 1:27 PM, Martijn Rijkeboer wrote: > Hi, > > Just out of curiosity, what has happend with WAPBL? There were some patches > floating around on tech@ in the last months of 2015, but then it became > quiet. I'm not complaining just curious. > > Kind regards, > > > Martijn Rijkeboer
Re: date not respect for 5.8 and 5.9
Like, because OpenBSD is for, like, REBELS, mn! Which is like, totally gnarly dude! On Thu, 31 Mar 2016 10:58:00 +0200 "Max Power" wrote: > Hi guys! > Why the release 5.8 and 5.9 did not comply with the canonical date > of the 1th November and of the 1th May? > > Thanks in advance for your reply.