wdc(4) caps probe & print
Hi,
I was going to propose the following kludge^Wpatch...
--- sys/dev/ic/wdc.c.orig 2016-09-14 22:00:16.0 -0400
+++ sys/dev/ic/wdc.c2017-09-02 18:57:21.0 -0400
@@ -1326,6 +1326,9 @@
at_poll) != CMD_OK)
continue;
+ (void)printf("%s: supports PIO mode %i\n",
+drvp->drive_name, i + 3);
+
/*
* If controller's driver can't set its PIO mode,
* set the highest one the controller supports
...when my eyes fell on the following comment:
in the same file:
> void
> wdc_print_caps(struct ata_drive_datas *drvp)
> {
> /* This is actually a lie until we fix the _probe_caps
> algorithm. Don't print out lies */
> #if 0
What's the deal with this? How is the _probe_caps routine broken enough
to justify omitting the printout?
--schaafuit.
fu^2: wdc_pcmcia and ATA mode
Hi, Now I've sent the general dmesg output, I'll provide the specific stuff concerning the card. On insertion: cd61 wrote: > wdc2 at pcmcia0 function 0 "TRANSCEND, TS64GCF400, " port 0x4000/16 > wd1 at wdc2 channel 0 drive 0: > wd1: 1-sector PIO, LBA48, 61064MB, 125059072 sectors > wd1(wdc2:0:0): using BIOS timings On removal: > wd1 detached > wdc2 detached NetBSD-7.1's boot.iso, used for comparison, additionally outputs the following: boot wrote: > wdc2: i/o mapped mode > wd1: drive supports PIO mode 4 Part of the sore spot is the 'i/o mapped mode'. As I noted before, NetBSD appears to support a 'memory mapped mode' as well, but no ATA, either. Nonetheless, the 'memory mapped mode' may well be faster. As to the second line, I wouldn't mind if OpenBSD would provide this information. I think I'll propose a patch... --schaafuit.
Re: Problem with key bindings with mutt under OpenBSD 6.1
On Sat, Sep 02, 2017 at 02:48:12PM +0200, Anton Lindqvist wrote: > On Sat, Sep 02, 2017 at 11:01:14AM +, C. L. Martinez wrote: > > Hi all, > > > > I have used mutt over several months under FreeBSD and RHEL/CentOS. I have > > migrated my desktop to OpenBSD 6.1 and I have a problem with mutt's package > > installed from official OpenBSD's repos (neomutt-20170306-gpgme-sasl). > > > > In my mutt's config file I have defined the following key bindings: > > > > # > > # Key bindings > > # > > bind index \CP sidebar-prev > > bind index \CN sidebar-next > > bind index \CO sidebar-open > > > > Problem is with "\CO". It doesn't works under OpenBSD but it works without > > problems under FreeBSD 11 or RHEL7/CentOS7. If I change "\CO" to "\CA" or > > "\CI" or "\CH", for example, works without problems ... Is it "\CO" defined > > by default under OpenBSD? How can I revert this behavior? > > $ stty discard undef; mutt > Perfect!! .. It is working.. Many thanks Anton. -- Greetings, C. L. Martinez
Thinkpad R40 varia
Just some notes on the damn thing:
Swapping the general battery clears the 'CMOS' memory. I surmise that
there is no seperate CMOS battery: I consider this a design flaw.
As with lots of IBM PC stuff of the era (since the PS/2?), there's a
'system partition' (or whatever they called it that week) that is
probably best preserved when swapping hdds (I'll be sure to make a
backup, just in case). The BIOS ('Phoenix FirstBIOS(tm)') setup is
reasonable, though: everything really important can be configured there
(or so it appears).
The lack of a serial port on the machine significantly limits its use
without a compatible docking station (I might try to get hold of one in
the future), or at least a PCMCIA serial port card.
The docking station connector's flaps don't appear to provide adequate
protection from the environment.
Again as (IIRC) common in the era it was produced, there are no flash
card ports, only {PCMCIA,CardBus}. Hence the wdc_pcmcia thread...
About the only documentation that I could find is the 'Hardware
Maintenance Manual'. I also have been able to track down a 'Service and
Troubleshooting Guide' and a 'Setup Guide'. E-mail me if you'd like
copies of any of these. I couldn't find a general luser manual, or
detailed specifications of the hardware (e.g. schematics).
There's what appears to be an extra port above the PCMCIA one, with a
female connector, but otherwise looking suspiciously similar, which I
haven't seen described (seperately) anywhere. I don't believe this is
for CardBus (though I could be wrong) -- for 2.5" hdds, maybe? If so, I
wonder if it supports hot-swapping...
--schaafuit.
dmesg of 'OpenBSD i386' 'cd61.iso' on 'Thinkpad R40'
Here's the promised dmesg.
--schaafuit.
cd61 wrote:
> OpenBSD 6.1 (RAMDISK_CD) #289: Sat Apr 1 13:58:25 MDT 2017
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD
> cpu0: Intel(R) Pentium(R) M processor 1300MHz ("GenuineIntel" 686-class) 1.30
> GHz
> cpu0:
> FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE,EST,TM2,PERF
> real mem = 535490560 (510MB)
> avail mem = 516141056 (492MB)
> mainbus0 at root
> bios0 at mainbus0: date 07/15/03, BIOS32 rev. 0 @ 0xfd7b0, SMBIOS rev. 2.31 @
> 0xe0010 (53 entries)
> bios0: vendor IBM version "1PET46WW (1.14 )" date 07/15/2003
> bios0: IBM 27223DG
> acpi0 at bios0: rev 2
> acpi0: tables DSDT FACP SSDT ECDT TCPA BOOT
> acpiec0 at acpi0
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 1 (AGP_)
> acpiprt2 at acpi0: bus 2 (PCI1)
> acpipwrres at acpi0 not configured
> acpitz at acpi0 not configured
> "PNP0C0D" at acpi0 not configured
> "PNP0C0E" at acpi0 not configured
> "PNP0303" at acpi0 not configured
> "IBM0057" at acpi0 not configured
> "PNP0501" at acpi0 not configured
> "PNP0400" at acpi0 not configured
> "IBM0071" at acpi0 not configured
> "PNP0C0A" at acpi0 not configured
> "ACPI0003" at acpi0 not configured
> "IBM0068" at acpi0 not configured
> bios0: ROM list: 0xc/0x1 0xe/0x1
> cpu0 at mainbus0: (uniprocessor)
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> pchb0 at pci0 dev 0 function 0 "Intel 82855PM Host" rev 0x03
> ppb0 at pci0 dev 1 function 0 "Intel 82855PM AGP" rev 0x03
> pci1 at ppb0 bus 1
> vga1 at pci1 dev 0 function 0 "ATI Radeon Mobility M7" rev 0x00
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> uhci0 at pci0 dev 29 function 0 "Intel 82801DB USB" rev 0x01: irq 11
> uhci1 at pci0 dev 29 function 1 "Intel 82801DB USB" rev 0x01: irq 11
> uhci2 at pci0 dev 29 function 2 "Intel 82801DB USB" rev 0x01: irq 11
> ehci0 at pci0 dev 29 function 7 "Intel 82801DB USB" rev 0x01: irq 11
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00
> addr 1
> ppb1 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0x81
> pci2 at ppb1 bus 2
> cbb0 at pci2 dev 0 function 0 "TI PCI1510 CardBus" rev 0x00: irq 11
> ipw0 at pci2 dev 2 function 0 "Intel PRO/Wireless 2100" rev 0x04: irq 11,
> address 00:04:23:81:d8:72
> "TI TSB43AB21 FireWire" rev 0x00 at pci2 dev 7 function 0 not configured
> fxp0 at pci2 dev 8 function 0 "Intel PRO/100 VE" rev 0x81, i82562: irq 11,
> address 00:06:1b:d3:19:22
> inphy0 at fxp0 phy 1: i82562ET 10/100 PHY, rev. 0
> cardslot0 at cbb0 slot 0 flags 0
> cardbus0 at cardslot0: bus 3 device 0 cacheline 0x8, lattimer 0xb0
> pcmcia0 at cardslot0
> pcib0 at pci0 dev 31 function 0 "Intel 82801DBM LPC" rev 0x01
> pciide0 at pci0 dev 31 function 1 "Intel 82801DBM IDE" rev 0x01: DMA, channel
> 0 configured to compatibility, channel 1 configured to compatibility
> wd0 at pciide0 channel 0 drive 0:
> wd0: 16-sector PIO, LBA, 35245MB, 72182773 sectors
> wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5
> atapiscsi0 at pciide0 channel 1 drive 0
> scsibus0 at atapiscsi0: 2 targets
> cd0 at scsibus0 targ 0 lun 0: ATAPI
> 5/cdrom removable
> cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
> "Intel 82801DB SMBus" rev 0x01 at pci0 dev 31 function 3 not configured
> "Intel 82801DB AC97" rev 0x01 at pci0 dev 31 function 5 not configured
> "Intel 82801DB Modem" rev 0x01 at pci0 dev 31 function 6 not configured
> usb1 at uhci0: USB revision 1.0
> uhub1 at usb1 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00
> addr 1
> usb2 at uhci1: USB revision 1.0
> uhub2 at usb2 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00
> addr 1
> usb3 at uhci2: USB revision 1.0
> uhub3 at usb3 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00
> addr 1
> isa0 at pcib0
> isadma0 at isa0
> pckbc0 at isa0 port 0x60/5 irq 1 irq 12
> pckbd0 at pckbc0 (kbd slot)
> wskbd0 at pckbd0: console keyboard, using wsdisplay0
> npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
> softraid0 at root
> scsibus1 at softraid0: 256 targets
> root on rd0a swap on rd0b dump on rd0b
Re: sudoreplay in sudo 1.8.21 on 6.2-snapshot
This is fixed in sudo 1.8.21p1. It's in ports now but you'll need to wait a bit for a prebuild package, though you can of course build your own. - todd
Re: Problem with key bindings with mutt under OpenBSD 6.1
On Sat, Sep 02, 2017 at 11:01:14AM +, C. L. Martinez wrote: > Hi all, > > I have used mutt over several months under FreeBSD and RHEL/CentOS. I have > migrated my desktop to OpenBSD 6.1 and I have a problem with mutt's package > installed from official OpenBSD's repos (neomutt-20170306-gpgme-sasl). > > In my mutt's config file I have defined the following key bindings: > > # > # Key bindings > # > bind index \CP sidebar-prev > bind index \CN sidebar-next > bind index \CO sidebar-open > > Problem is with "\CO". It doesn't works under OpenBSD but it works without > problems under FreeBSD 11 or RHEL7/CentOS7. If I change "\CO" to "\CA" or > "\CI" or "\CH", for example, works without problems ... Is it "\CO" defined > by default under OpenBSD? How can I revert this behavior? $ stty discard undef; mutt
Problem with key bindings with mutt under OpenBSD 6.1
Hi all, I have used mutt over several months under FreeBSD and RHEL/CentOS. I have migrated my desktop to OpenBSD 6.1 and I have a problem with mutt's package installed from official OpenBSD's repos (neomutt-20170306-gpgme-sasl). In my mutt's config file I have defined the following key bindings: # # Key bindings # bind index \CP sidebar-prev bind index \CN sidebar-next bind index \CO sidebar-open Problem is with "\CO". It doesn't works under OpenBSD but it works without problems under FreeBSD 11 or RHEL7/CentOS7. If I change "\CO" to "\CA" or "\CI" or "\CH", for example, works without problems ... Is it "\CO" defined by default under OpenBSD? How can I revert this behavior? Thanks. -- Greetings, C. L. Martinez
fu: wdc_pcmcia and ATA mode
To: misc@openbsd.org Subject: fu: wdc_pcmcia and ATA mode I wrote: > I'm to install OpenBSD on an old Thinkpad, but I first need to dump > the curr hdd contents, using the install cd, to a large CF card, via > a PCMCIA adapter. > > The pcmcia stuff is correctly detected by the kernel, but wdc_pcmcia > only appears to access the device in pcmcia mode (1-sector PIO), > killing performance. I'm sure the CF card supports ATA mode and DMA > as it's been used in the past as an ATA device through (guess what) > an appropriate adapter. Okay, I got a little further with this, but it didn't resolve the issue. The adapter is a TS0MCF2PC. I haven't been able to open it up (glue is involved and I simply don't have a thin enough screwdriver or knife to avoid breaking the plastic). The flash card I used during the above is an old SanDisk SDCFB 256M; it was for testing, only. Yesterday the card I actually intend to use arrived, a Transcend TS64GCF400. However, even that card, which is specified to support 'UDMA7', is used by OpenBSD in what NetBSD (I tried it just in case) appears to call 'i/o mapped mode'. 'memory mapped mode' appears to be an option on the other side of the fence (or bikeshed?) there, but the straightforward route would IMO still be to treat the card as an ATA device. This leaves me with two concrete questions: 1) Does the cbb actually allow the card to work in ATA mode? 2) If so, why does OpenBSD not support it? Perhaps, with help (I find modern kernels *slightly* overcomplicated, so I'm bound to get some things wrong), I can then provide a patch to at least work around this issue. dmesg output will be provided later today (not via the 10-finger interface ). --schaafuit.
Re: How do you deal with many disks?
Hi Otto, Thanks for your reply. On Sat, Sep 02, 2017 at 08:25:09AM +0200, Otto Moerbeek wrote: | > Does anyone have a better approach? | | Why in rc.local? This is a one time action only, right? Uhm, that's actually a good question. I thought `MAKEDEV all` deleted all dev entries before repopulating them, but I was obviously mistaken. I kept cranking the number in /etc/rc.local when adding disks (real or softraid crypto), but that's definitely not necessary. [root@pom] # ls -l sd29c brw-r- 1 root operator4, 546 Sep 2 09:42 sd29c [root@pom] # sh MAKEDEV all [root@pom] # ls -l sd29c brw-r- 1 root operator4, 546 Sep 2 09:42 sd29c OK, ignore me :) Sorry for the noise! Just adding the devices once like you suggest is sufficient. Paul -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: How do you deal with many disks?
Hi Jacqueline, Thanks for your reply! On Fri, Sep 01, 2017 at 07:28:22PM -0700, Jacqueline Jolicoeur wrote: | This is just an idea. | | Can you simply edit, | | /usr/src/etc/etc.`uname -p`/MAKEDEV.md | | to produce a /dev/MAKEDEV which will create all 32 device files by | default? I could do that, but then I'd have to carry this as a local diff (it's unlikely to get committed, since so many sd devices is quite unusual). Cheers, Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: How do you deal with many disks?
On Fri, Sep 01, 2017 at 10:46:05PM BST, Paul de Weerd wrote:
> I make extensive use of softraid crypto on two internal and a bunch of
> external disks. This results in up to 32 sd(4) devices attaching to
> my machine. However, by default MAKEDEV only creates 10 sd device
> nodes in /dev.
>
> How do people deal with this? For now, I've got the following in
> /etc/rc.local:
>
> # Create extra entries in /dev for all (softraid) disks
> cd /dev
> for X in `jot 25 10`
> do
> [ -f sd${X}c ] || sh MAKEDEV sd${X}
> done
>
> Does anyone have a better approach?
Hi Paul,
Using /dev/MAKEDEV.local is the standard way to do this.
Raf
> Cheers,
>
> Paul 'WEiRD' de Weerd
>
> OpenBSD 6.2-beta (GENERIC.MP) #44: Fri Aug 25 19:16:21 MDT 2017
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 34243919872 (32657MB)
> avail mem = 33199071232 (31661MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec410 (88 entries)
> bios0: vendor Dell Inc. version "A12" date 05/06/2015
> bios0: Dell Inc. OptiPlex 9020
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC FPDT SLIC LPIT SSDT SSDT SSDT HPET SSDT MCFG
> SSDT ASF! DMAR
> acpi0: wakeup devices UAR1(S3) PXSX(S4) RP01(S4) PXSX(S4) PXSX(S4) PXSX(S4)
> RP05(S4) PXSX(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S3) EHC2(S3) XHC_(S4)
> HDEF(S4) PEG0(S4) [...]
> 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) Core(TM) i7-4770 CPU @ 3.40GHz, 3392.59 MHz
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: TSC frequency 3392585040 Hz
> 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.2.4, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3392.15 MHz
> cpu1:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 4 (application processor)
> cpu2: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3392.15 MHz
> cpu2:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
> 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) Core(TM) i7-4770 CPU @ 3.40GHz, 3392.15 MHz
> cpu3:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
> 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) Core(TM) i7-4770 CPU @ 3.40GHz, 3392.15 MHz
> cpu4:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
> 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) Core(TM) i7-4770 CPU @ 3.40GHz, 3392.15 MHz
> cpu5:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG
Re: OpenBSD 6.1-stable lock up
Am 1. September 2017 06:38:49 MESZ schrieb Philipp Buehler : >Hello, > >Am 01.09.2017 00:33 schrieb Maxim Bourmistrov: >> 0/232/64 mbuf 2048 byte clusters in use (current/peak/max) >> 423/2865/120 mbuf 2112 byte clusters in use (current/peak/max) >> 0/160/64 mbuf 4096 byte clusters in use (current/peak/max) >> 0/200/64 mbuf 8192 byte clusters in use (current/peak/max) > >I've seen this before - including a kind of "lock up". >How does one reach a peak/current way over the maximum - and 2112 byte >mcl? >IIRC, there was activity in this area changing allocation and >statistics. Hm, could this be the same performance regression as VLANs saw? http://www.grenadille.net/post/2017/02/13/What-happened-to-my-vlan The post and the one on tech@ don't mention the version but as it was a discussion between OpenBSD devs I guess it was what became 6.1 a few month later. I think I've heard or read something about improvements in this area (on BSDnow or undeadly) so maybe you could try a 6.2- BETA. Regards, Florian
