Re: Sky Lake-E PCI ids.

On 2/26/21 7:24 AM, Jonathan Gray wrote: As the ids are used on more than just Skylake-E here is another diff. Though I think these ids are shared with Core X Skylake. So perhaps giving up on a marketing name is indeed the thing to do. Indeed, Intel made quite a mess in this, but I think this

Re: Sky Lake-E PCI ids.

The marketing name is 'Xeon Processor Scalable Family' Intel Xeon Bronze 3XXX processor Intel Xeon Gold 6XXF processor Intel Xeon Platinum 6XXF processor Intel Xeon Platinum 8XXF processor Intel Xeon Silver 4XXX processor Intel Xeon Gold 5XXX processor Intel Xeon Platinum 6XXX processor Intel

Re: Sky Lake-E PCI ids.

Patch below is less verbose and using Skylake-E name. diff --git a/sys/dev/pci/pcidevs b/sys/dev/pci/pcidevs index ba975d05548..8c629ba9e1a 100644 --- a/sys/dev/pci/pcidevs +++ b/sys/dev/pci/pcidevs @@ -4188,6 +4188,58 @@ product INTEL ATOMC2000_PCU_SMB 0x1f3c Atom C2000 PCU SMBus product

Re: Sky Lake-E PCI ids.

Tom Cosgrove in private email pointed out that even Intel is not consistent in processors naming and provided enough evidence that this is indeed 'Skylake-E'. I'll submit corrected patch asap. On 2/25/21 12:22 PM, Karel Gardas wrote: Less verbose output patch below. Still using 'Sky Lake

Re: Sky Lake-E PCI ids.

Less verbose output patch below. Still using 'Sky Lake-E' since I think it's more close to OpenBSD's 'Apollo Lake' and 'Gemini Lake' style then would be 'Skylake-E'. diff --git a/sys/dev/pci/pcidevs b/sys/dev/pci/pcidevs index ba975d05548..a9209c75bfc 100644 --- a/sys/dev/pci/pcidevs +++

Re: Sky Lake-E PCI ids.

On 2/25/21 10:34 AM, Jonathan Gray wrote: On Wed, Feb 24, 2021 at 05:01:50PM +0100, Karel Gardas wrote: Hello, attach patch adds some SkyLake-E related PCI ids. Tested on Kontron/Fujitsu D3598-B with Intel Xeon W-2123. Thanks for review, comment(s) and/or commit. Karel I can only find

Re: Sky Lake-E PCI ids.

Series I2C  product INTEL 200SERIES_I2C_2    0xa2e1    200 Series I2C  product INTEL 200SERIES_I2C_3    0xa2e2    200 Series I2C On 2/24/21 5:01 PM, Karel Gardas wrote: Hello, attach patch adds some SkyLake-E related PCI ids. Tested on Kontron/Fujitsu D3598-B with Intel Xeon W-2123. Thanks

Sky Lake-E PCI ids.

Hello, attach patch adds some SkyLake-E related PCI ids. Tested on Kontron/Fujitsu D3598-B with Intel Xeon W-2123. Thanks for review, comment(s) and/or commit. Karel diff --git a/sys/dev/pci/pcidevs b/sys/dev/pci/pcidevs index ba975d05548..10d98d3ce2b 100644 --- a/sys/dev/pci/pcidevs +++

Re: piixpm(4) on ATI SBx00

On 1/22/20 5:25 AM, Ted Unangst wrote: Karel Gardas wrote: On 1/21/20 2:33 AM, Claudio Jeker wrote: Please test this since I can't test this properly at the moment. Sorry for delay with testing. Used today current to update and dmesg and diff of last fix and current dmesg are attached

Re: piixpm(4) on ATI SBx00

On 1/21/20 2:33 AM, Claudio Jeker wrote: Please test this since I can't test this properly at the moment. Would like to, but all hunks fail on today current: solo$ patch < /tmp/piixpm.patch Hmm...  Looks like a unified diff to me... The text leading up to this was:

Re: piixpm(4) on ATI SBx00

Current and patched current dmesg diff below and both dmesgs attached.  real mem = 4009230336 (3823MB) -avail mem = 3875258368 (3695MB) +avail mem = 3875254272 (3695MB)  mpath0 at root  scsibus0 at mpath0: 256 targets  mainbus0 at root @@ -108,20 +108,9 @@  spdmem0 at iic0 addr 0x50: 2GB DDR3

Re: OpenBSD on IBM Power.

Since that time various people tried various things -- for reference see ppc@ but personally most closest thing of running OpenBSD on POWER I've seen so far was OpenBSD in amd64/qemu which was kind of PITA performance wise. OpenBSD/macppc is not working in qemu at all and although

Re: httpd logging X509 cert subject when CA option is used.

Any issues with the patch now? Anything I shall improve to get that into acceptable/comitable state? Thanks, Karel On Fri, 1 Feb 2019 17:48:46 +0100 Karel Gardas wrote: > On Fri, 1 Feb 2019 16:53:14 +0100 > Sebastian Benoit wrote: > > > > + if (clt->cl

Re: httpd logging X509 cert subject when CA option is used.

On Fri, 1 Feb 2019 16:53:14 +0100 Sebastian Benoit wrote: > > + if (clt->clt_remote_user == NULL && > > + clt->clt_tls_ctx != NULL && > > + (srv_conf->tls_flags & TLSFLAG_CA) && > > + stravis(, tls_peer_cert_subject(clt->clt_tls_ctx), > >

httpd logging X509 cert subject when CA option is used.

Hello, I'd like to have X509 peer's cert subject name logged in some form when ca option in httpd.conf is used. That is, we do have X509 verified client accessing web resource. Following patch implements this behavior for combined logging style and for the case http connection is not

Re: fix compilation failure when sr_debug is defined.

Hello, correct version of the patch is below. The previos one was wrong. Thanks, Karel Index: sys/arch/amd64/amd64/machdep.c === RCS file: /cvs/src/sys/arch/amd64/amd64/machdep.c,v retrieving revision 1.248 diff -u -p -u -r1.248

fix compilation failure when sr_debug is defined.

Hello, following small patch fixes compilation failure when SR_DEBUG is defined in softraidvar.h which results in definition of DPRINTF which results in error about already defined macro in machdep.c Index: arch/amd64/amd64/machdep.c

cdce0 troubles on RPi3, few ways to fix, which one to choose?

Hi, I do have 2 USB ethernet adapters based on Realtek 8153: TP-Link UE 300 Lenovo Thinkpad USB 3.0 Gigabit Adapter both adapters work well with 6.3-current on amd64 platform. If however I try to use them on RPi3 with 6.3-current, both lead to system freeze. As I see it now, there may be two

Add support note for Theobroma RK3399-Q7 module

Hi, Mark Kettenis confirmed on -arm mailing list support of -current for Theobroma's RK3399-Q7 module together with Haikou Q7 Dev Kit. Patch below fixes this omission on arm64 platform page. Thanks, Karel ? papers/eurobsdcon_2013_kde4/.new.img69.png Index: arm64.html

Re: elf.h: define SHT_SYMTAB_SHNDX

rrent. Hence pinging. > > > > Thanks! > > Karel > > > > On Tue, 16 Jan 2018 11:51:53 +0100 > > Martin Pieuchot <m...@openbsd.org> wrote: > > > > > On 15/01/18(Mon) 23:11, Karel Gardas wrote: > > > > patch below defines SHT_SYMTAB_S

Re: elf.h: define SHT_SYMTAB_SHNDX

ping. The addition of SHT_SYMTAB_SHNDX is not just estetic improvement but fixes GHC HEAD build failure on OpenBSD 6.2-current. Hence pinging. Thanks! Karel On Tue, 16 Jan 2018 11:51:53 +0100 Martin Pieuchot <m...@openbsd.org> wrote: > On 15/01/18(Mon) 23:11, Karel Gardas wrote:

Re: elf.h: define SHT_SYMTAB_SHNDX

On 01/16/18 11:51, Martin Pieuchot wrote: On 15/01/18(Mon) 23:11, Karel Gardas wrote: patch below defines SHT_SYMTAB_SHNDX which is required for usage of SHN_XINDEX which got added/defined during October 2017 by mpi. See: http://www.sco.com/developers/gabi/latest/ch4.sheader.html

elf.h: define SHT_SYMTAB_SHNDX

Hello, patch below defines SHT_SYMTAB_SHNDX which is required for usage of SHN_XINDEX which got added/defined during October 2017 by mpi. See: http://www.sco.com/developers/gabi/latest/ch4.sheader.html: SHT_SYMTAB_SHNDX This section is associated with a symbol table section and is

Re: elf.h

Hi, below is last version of my attempt to migrate elf_abi.h to elf.h. This version solves devel/libdwarf and devel/valgrind failures reported on ports@ by Christian Weisgerber Thanks, Karel ? .cvsignore Index: distrib/sets/lists/comp/mi

Re: elf.h

On Fri, 14 Jul 2017 20:44:12 +0200 Karel Gardas <gard...@gmail.com> wrote: > > Hi, > > below is another diff of my elf.h cleanup work. I'm still keeping > /usr/include/elf_abi.h to not break GHC and all > Haskell based ports. > > What I have done in this versi

Re: introduction of an additional non-POSIX function in libpthread

Why your patch defines MALLOC_STATS? -/* #define MALLOC_STATS */ +#define MALLOC_STATS On Tue, Jul 18, 2017 at 2:43 PM, David CARLIER wrote: > Ah I recognise you you re Mozilla contributor right ? You re probably right > but that was just an example eventhough I admit it s

Re: elf.h

On Fri, 14 Jul 2017 20:44:12 +0200 Karel Gardas <gard...@gmail.com> wrote: > So with this base is compilable and runnable on AMD64. W.r.t. ports, yes, > some of those fails. I've not investigated more closely strange failures > which may be a cause of me not cleaning up f

Re: elf.h

Hi, below is another diff of my elf.h cleanup work. I'm still keeping /usr/include/elf_abi.h to not break GHC and all Haskell based ports. What I have done in this version is went thorough whole spec and check everything in the exec_elf.h. What's not in spec I commented out with "not in spec"

Re: elf.h

On Tue, 4 Jul 2017 11:48:27 +0200 Martin Pieuchot wrote: > Hello, > > I think that moving towards is a good thing. However are you > sure that provides all the definitions required by > ? Not yet. At least a lot of machine related definitions are missing, but they are not

elf.h

Hello, I'm curious if it's possible to provide /usr/include/elf.h file on OpenBSD to improve its niceness to software porting from other Unixes. Following patch adds this for me and is tested with GHC where I'd like to kill code like: #if !defined(openbsd_HOST_OS) # include #else /*

Re: attach SR drive by force even if not all chunks provide native metadata

On Tue, Sep 27, 2016 at 7:27 PM, Joel Sing <j...@sing.id.au> wrote: > On Saturday 24 September 2016 00:13:47 Karel Gardas wrote: >> Hello, >> >> following patch fixes issue while attempting to attach SR RAID1 drive >> where not all chunks provide native metadat

attach SR drive by force even if not all chunks provide native metadata

Hello, following patch fixes issue while attempting to attach SR RAID1 drive where not all chunks provide native metadata. I.e. one chunk is dd zeroed. The complain of SR is good one, but I'd think that force parameter should overcome it and really enforce SR to attach such drive. Thanks, Karel

Re: mbuf cluster and socket buffer limits

On Fri, Sep 2, 2016 at 6:59 PM, Alexander Bluhm wrote: > Hi, > > To move our network performance to modern high bandwith and high > latency characteristics, we have to increase the socket buffer size > limit. That also implies more mbuf clusters to avoid running out > of

Re: machine slow with latest snapshot (bufcache related?) on sparc64

You should include dmesg or even report as proper bugreport. On Fri, Apr 29, 2016 at 10:51 PM, Markus Lude wrote: > Hello, > > with latest snapshot I've short hangs on my (good old) SUN Blade 100. > The desktop clocks often shows jumps for several seconds. > I noticed that

Re: New scheduler for OpenBSD

On Fri, Mar 18, 2016 at 6:02 PM, Michal Mazurek wrote: > BFS has one shared queue for all CPUs, maybe there is a very good reason > for that, we'll see. Michal, first of all congrats to optimistic results in interactive workloads. Honestly I'm a little bit worried about

Re: vmm update

Not sure, but on misc you can search for "vmm uvm_fault in vmware player/workstation when Intel VT/AMD-v not enabled" thread from which it looks like vmm requires extended-page tables virtualization feature. Certainly this is not presented on my T500 so I would guess it's neither on your T400.

Re: WAPBL implementation

well, wapbl looks fantastic so far. I'm now hammering this on top of SR RAID1C and will let you know about any issues... Thanks! Karel On Sat, Nov 21, 2015 at 12:41 PM, Karel Gardas <gard...@gmail.com> wrote: > RAID1. So here is my question: is there any possibility to convince >

Re: WAPBL implementation

On Sat, Nov 21, 2015 at 8:28 PM, Michael McConville wrote: > I agree that this is very cool. It's probably also worth mentioning that > there's a long discussion on NetBSD's tech-kernel@ right now about a > WABPL-related panic. Not sure whether that's relevant to this diff. If

Re: WAPBL implementation

Walter, this is really beautiful at least from the performance point of view. My benchmarks shows: rsync: 3m27s -> 1m20s rm: 2m13s -> 9s so speed increase is here as reported by various wapbl papers which is really nice. Anyway, I'd also like to use that with my implementation of checksumming

By four CRC32

Hello, I'm curious what's need to be done in order to have by-four version of CRC32 enabled by default let's say at least on amd64? Attached patch is quite aggressive as I put an option into generic GENERIC, but still I hope it may be usable as a starting point. Performance of CRC32 went up from

Re: toy zones for openbsd - an undergrad operating systems course assignment

This is nice! Am I right assuming zone exec is a short-cut for not need to implement Solaris' zlogin functionality? I'm not sure if I'm as ordinary global zone user on Solaris able to start process in another zone where I don't have login credentials. So that may be difference between your zone

Re: toy zones for openbsd - an undergrad operating systems course assignment

On Fri, Oct 30, 2015 at 1:11 PM, David Gwynne <da...@gwynne.id.au> wrote: > >> On 30 Oct 2015, at 9:13 PM, Karel Gardas <gard...@gmail.com> wrote: >> >> This is nice! Am I right assuming zone exec is a short-cut for not >> need to implement Solaris' zl

[WIP PATCH] SR RAID1 checksumming support V3

Hello, attached is my work in progress on checksumming support for softraid RAID1. Currently it does: - computation of checksums (crc32) - verification of checksums - hang-over to another chunk (restart wu) in case of checksum error - properly handle errors happening on all chunks -

[WIP PATCH] SR RAID1 checksumming support V2

Hello, attached my work in progress on checksumming support for softraid RAID1. Currently it does: - computation of checksums (crc32) - verification of checksums - hang-over to another chunk (restart wu) in case of checksum error - properly handle errors happening on all chunks - signal bad

[WIP PATCH] SR RAID1 checksumming support

Hello, attached my work in progress on checksumming support for softraid RAID1. Currently it does just: - computation of checksums (crc32) - verification of checksums - signal bad checksum to console and to sensors E.g.: $ sysctl hw.sensors.softraid0 hw.sensors.softraid0.raw0=0 (sd0f), OK

Re: softdep by default on AMD64

On Thu, Jul 30, 2015 at 2:01 PM, Christian Weisgerber na...@mips.inka.de wrote: On 2015-07-30, Karel Gardas gard...@gmail.com wrote: discussion. So far what I've read is that softdep does have some unreliability issues on somehow limited platforms: either small kernel memory or slow disk

Re: softdep by default on AMD64

W.r.t. code or fixes, I'm afraid this is not only about developer work but probably also about simple work analysis and kind of direction discussion. So far what I've read is that softdep does have some unreliability issues on somehow limited platforms: either small kernel memory or slow disk

Re: softraid and 4096-byte sectors 'fixed'

On Wed, Jul 22, 2015 at 6:43 PM, Kenneth Westerback kwesterb...@gmail.com wrote: On 22 July 2015 at 12:36, Ted Unangst t...@tedunangst.com wrote: Kenneth R Westerback wrote: CAVEAT: The metadata version has changed so new volumes you create will not be loadable on boxes running older versions

Re: doas failsafe

On Tue, Jul 21, 2015 at 5:30 PM, li...@wrant.com wrote: so, why not type su rather than doas? I will not type doas. Do you? If doas supplies kind of sudo functionality than I would rather use it instead of su and being root all the time. So yes, I will.

Re: [PATCH] fix write error handling on SR RAID1

On Sat, Jul 11, 2015 at 3:44 PM, Joel Sing j...@sing.id.au wrote: Your analysis is incorrect - offlining of chunks is handled via sr_ccb_done(). If lower level I/O indicates an error occurred then the chunk is marked offline, providing that the discipline has redundancy (for example, we do

[PATCH] fix write error handling on SR RAID1

Hello, I think I've found a bug on software RAID1 implementation of handling write errors. IMHO code should check if every write to every chunk succeed. If not, then there is an error which it needs to handle. Proposed patch handles such error by off-lining the problematic drive. The patch

[PATCH] fix compilation failure with SR_DEBUG enabled.

Hello, following patch fixes compilation failure on AMD64 when SR_DEBUG is enabled. Thanks, Karel Index: dev/softraid_crypto.c === RCS file: /cvs/src/sys/dev/softraid_crypto.c,v retrieving revision 1.117 diff -u -p -u -r1.117

Re: softraid checksumming discipline.

On Thu, Jun 18, 2015 at 6:32 PM, Joel Sing j...@sing.id.au wrote: Re adding some form of checksumming, it only seems to make sense in the case of RAID 1 where you can decide that the data on a disk is invalid, then fail the read and pull the data from another drive. That coupled with block

Re: softraid checksumming discipline.

Joel, yes, I will work on your recommended RAID1 with checksumming of course. Just forgotten to add that. Thanks, Karel On Thu, Jun 18, 2015 at 10:40 PM, Karel Gardas gard...@gmail.com wrote: On Thu, Jun 18, 2015 at 6:32 PM, Joel Sing j...@sing.id.au wrote: Re adding some form of checksumming

softraid checksumming discipline.

Hello, I'm curious if anybody is working on implementing block-level checksumming on softraid? Backgroud: I'm comming from Solaris 11/ZFS world and I like ZFS's focus on data integrity from drive level up to the RAM. I've been thinking about OpenBSD and how to get the same with minimalistic