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
+++ b
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
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 a
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
+++ b
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
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 IN
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 X
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
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
===
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 m
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
===
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
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 authenticat
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(&user, tls_peer_cert_subject(clt->clt_tls_ctx),
>
>
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
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
netbsd/macp
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 SDR
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:
-
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 att
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 your attempts since I thi
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 the machine is running
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
/* openbsd
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 required if neither
On Wed, 5 Jul 2017 12:11:32 +0200
Martin Pieuchot wrote:
> Exporting hurts, I don't think that Solaris includes it.
> With it programs will compile on OpenBSD with but might require
> on other OSes.
fortunately OpenBSD base neither requires sys/types.h.
> > > What would it take to convert ba
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"
On Fri, 14 Jul 2017 20:44:12 +0200
Karel Gardas 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 fs from previous sna
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 not extremely widely
>
l
On Fri, 14 Jul 2017 20:44:12 +0200
Karel Gardas 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 version is went thorough who
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 them.
>
> This diff inclu
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
On Tue, Sep 27, 2016 at 7:27 PM, Joel Sing 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 metadata. I.e. one chunk is dd
&g
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
effor
On Thu, Jun 18, 2015 at 6:32 PM, Joel Sing 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
> level "healin
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 wrote:
> On Thu, Jun 18, 2015 at 6:32 PM, Joel Sing wrote:
>>
>> Re adding some form of checksumming, it onl
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 softra
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 compile
On Fri, Jul 10, 2015 at 9:34 PM, Chris Cappuccio wrote:
> My first impression, offlining the drive after a single chunk failure
> may be too aggressive as some errors are a result of issues other than
> drive failures.
Indeed, it may look as too aggressive, but is my analysis written in
comment c
On Sat, Jul 11, 2015 at 3:44 PM, Joel Sing 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 not offline
>
On Tue, Jul 21, 2015 at 5:30 PM, 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.
On Wed, Jul 22, 2015 at 6:43 PM, Kenneth Westerback
wrote:
> On 22 July 2015 at 12:36, Ted Unangst 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 of OpenBSD.
>>>
>>> CAVEAT: You
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 drive
On Thu, Jul 30, 2015 at 11:19 AM, Theo de Raadt wrote:
> Your mail sounds like a beg. Perhaps I am being too sensitive.
Spent already some time in netbsd/bitrig wapbl code to see what's
relevant for Open and how to structure it to small sensible patches to
push for review. This will take some e
On Thu, Jul 30, 2015 at 2:01 PM, Christian Weisgerber
wrote:
> On 2015-07-30, Karel Gardas 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 d
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
hw.sens
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 checks
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
- "self-healing"
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
==
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 require
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
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 wrote:
> On 15/01/18(Mon) 23:11, Karel Gardas wrote:
> > patch belo
> > Thanks!
> > Karel
> >
> > On Tue, 16 Jan 2018 11:51:53 +0100
> > 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
> > > &g
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 and
On Fri, Oct 30, 2015 at 1:11 PM, David Gwynne wrote:
>
>> On 30 Oct 2015, at 9:13 PM, Karel Gardas wrote:
>>
>> 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
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 3
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 f
.
So 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 wrote:
> RAID1. So here is my question: is there any possibility to convince
> current WAPBL code
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 I've found the same
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. Plea
> +void
> +xen_disable_emulated_devices(struct xen_softc *sc)
> +{
> +#if defined(__i386__) || defined(__amd64__)
just a nitpick, not in a position to comment on your patches but this
has caught my eyes. So far everything was just generic or amd64
specific. Now you ifdef also for i386. Is that int
59 matches
Mail list logo