Re: VisionFive 2
On Tue, Aug 01, 2023 at 11:11:43PM +0200, Robert Palm wrote: > I own a VF 2 version 1.2a and can successfully install / boot the machine. > > The inner network port (dwqe1) works at 100 full duplex and receives ipv4 > via DHCP. > > The outer port currently doesn't seem to get an ip, but gets active and in > full-duplex 100. > > It seems a lot depends on proper .dtb files (which kind users shared with me). > > How did you create the .dtb files ? I don't know about the rest of the questions, but you can update a .dtb with a program from the ports in devel/dtc. - pjp@polarstern$ more pkg/DESCR The Device Tree Compiler (DTC) compiles device-tree descriptions for booting PowerPC kernels on embedded systems without OpenFirmware. Optional dependency: install the bash package if you wish to use dtdiff. - There is something similar in Linux. Basically you would convert the .dtb to a .dts, edit it and convert the .dts back to .dtb. I hope that answers one question. Best Regards, -peter > Do you plan to update them ? > > They seem to be quite different to the "official" starfive releases (which > don't work for me with OpenBSD). > > Do you plan more work on the VF2 ? > > Thanks! > -- Over thirty years experience on Unix-like Operating Systems starting with QNX.
VisionFive 2
I own a VF 2 version 1.2a and can successfully install / boot the machine. The inner network port (dwqe1) works at 100 full duplex and receives ipv4 via DHCP. The outer port currently doesn't seem to get an ip, but gets active and in full-duplex 100. It seems a lot depends on proper .dtb files (which kind users shared with me). How did you create the .dtb files ? Do you plan to update them ? They seem to be quite different to the "official" starfive releases (which don't work for me with OpenBSD). Do you plan more work on the VF2 ? Thanks!
Patch: support for Dell HBA350i
Hello, We have some Dell PowerEdge R350 equipped with Dell HBA350i (RAID) but this hardware isn't recognized by OpenBSD 7.3. There seems to be 8 product identifiers associated to the chip involved (SAS3816). So I've added all of them to the list, accordingly to the diff file attached to this email. Then I've built an OpenBSD release (amd64) and the installation process has been successful (dmesg attached, see mfii). pcidump reports that the product identifier of the tested hardware is 0x10e6 (details attached). So it works fine for this one but I don't know for the 7 others. Regards, Mathieu J. PAPINEAU Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. pcidevs_mfii.diff Description: pcidevs_mfii.diff 3:0:0: Symbios Logic unknown 0x: Vendor ID: 1000, Product ID: 10e6 0x0004: Command: 0007, Status: 0010 0x0008: Class: 01 Mass Storage, Subclass: 04 RAID, Interface: 00, Revision: 00 0x000c: BIST: 00, Header Type: 00, Latency Timer: 00, Cache Line Size: 00 0x0010: BAR mem prefetchable 64bit addr: 0x00400010/0x0010 0x0018: BAR mem prefetchable 64bit addr: 0x0040/0x0010 0x0020: BAR mem 32bit addr: 0x91e0/0x0010 0x0024: BAR io addr: 0x3000/0x0100 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 1028 Product ID: 2172 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 01 Line: ff Min Gnt: 00 Max Lat: 00 0x0040: Capability 0x01: Power Management State: D0 0x0050: Capability 0x05: Message Signalled Interrupts (MSI) Enabled: yes 0x0070: Capability 0x10: PCI Express Max Payload Size: 256 / 1024 bytes Max Read Request Size: 512 bytes Link Speed: 8.0 / 8.0 GT/s Link Width: x4 / x8 0x0100: Enhanced Capability 0x01: Advanced Error Reporting 0x0148: Enhanced Capability 0x04: Power Budgeting 0x0158: Enhanced Capability 0x0e: Alternate Routing ID 0x0168: Enhanced Capability 0x19: Secondary PCIe Capability 0x0188: Enhanced Capability 0x26: Physical Layer 16.0 GT/s 0x01b0: Enhanced Capability 0x27: Lane Margining at the Receiver 0x0248: Enhanced Capability 0x0b: Vendor-Specific 0x0348: Enhanced Capability 0x0b: Vendor-Specific 0x0380: Enhanced Capability 0x25: Data Link Feature 0x00b0: Capability 0x11: Extended Message Signalled Interrupts (MSI-X) Enabled: no; table size 128 (BAR 0:8192) OpenBSD 7.3 (GENERIC.MP) #1: Mon Jul 31 18:19:52 CEST 2023 r...@blu.mshome.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 16868401152 (16086MB) avail mem = 16337752064 (15580MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.2 @ 0x7b3b9000 (45 entries) bios0: vendor Dell Inc. version "1.6.3" date 02/22/2023 bios0: Dell Inc. PowerEdge R350 efi0 at bios0: UEFI 2.7 efi0: Dell Inc. rev 0x3060101 acpi0 at bios0: ACPI 6.1 acpi0: sleep states S0 S5 acpi0: tables DSDT FACP SSDT SSDT WD__ HPET APIC MCFG SSDT SSDT LPIT WSMT SSDT DBGP DBG2 SSDT SPCR SSDT HEST BERT ERST EINJ PTDT DMAR FPDT acpi0: wakeup devices PEG1(S0) PEG2(S0) XHCI(S0) XDCI(S0) HDAS(S0) CNVW(S0) RP01(S0) RP02(S0) RP03(S0) RP04(S0) RP05(S0) RP06(S0) RP07(S0) RP08(S0) RP09(S0) RP10(S0) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 2399 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) E-2324G CPU @ 3.10GHz, 3095.35 MHz, 06-a7-01 cpu0:
Re: axppmic(4): axp313a support
> Date: Tue, 01 Aug 2023 22:34:05 +0900
> From: SASANO Takayoshi
>
> hi,
>
> > maybe add a note that the data sheet is wrong for dcdc3?
>
> The datasheet issue is written in Linux code at
> https://elixir.bootlin.com/linux/v6.5-rc4/source/drivers/regulator/axp20x-regulator.c#L725
>
> > /*
> > * This is deviating from the datasheet. The values here are taken from the
> > * BSP driver and have been confirmed by measurements.
> > */
> > static const struct linear_range axp313a_dcdc3_ranges[] = {
> > REGULATOR_LINEAR_RANGE(50, 0, 70, 1),
> > REGULATOR_LINEAR_RANGE(122, 71, 102, 2),
> > };
>
> It means 500-1200mV(10mV*70 step) and 1220-1840mV(20mV*31 step),
> they want to say dcdc3's 1650-1840mV range is something strange.
>
> AXP313A datasheet clearly says that dcdc3 is 0.5-1.2V and 1.22-1.84V.
> https://github.com/mangopi-sbc/aw-doc/blob/main/pmic/AXP313A_Datasheet_V1.0_cn.pdf
>
> So I think no need to add any notes.
Ah, I was looking at an older version of the datasheet (v0.1). Looks
like they fixed it. So yes, your diff is good as-is. No need to add
any notes.
ok kettenis@
Re: axppmic(4): axp313a support
hi,
> maybe add a note that the data sheet is wrong for dcdc3?
The datasheet issue is written in Linux code at
https://elixir.bootlin.com/linux/v6.5-rc4/source/drivers/regulator/axp20x-regulator.c#L725
> /*
> * This is deviating from the datasheet. The values here are taken from the
> * BSP driver and have been confirmed by measurements.
> */
> static const struct linear_range axp313a_dcdc3_ranges[] = {
> REGULATOR_LINEAR_RANGE(50, 0, 70, 1),
> REGULATOR_LINEAR_RANGE(122, 71, 102, 2),
> };
It means 500-1200mV(10mV*70 step) and 1220-1840mV(20mV*31 step),
they want to say dcdc3's 1650-1840mV range is something strange.
AXP313A datasheet clearly says that dcdc3 is 0.5-1.2V and 1.22-1.84V.
https://github.com/mangopi-sbc/aw-doc/blob/main/pmic/AXP313A_Datasheet_V1.0_cn.pdf
So I think no need to add any notes.
--
SASANO Takayoshi (JG1UAA)
Re: pf(4) may cause relayd(8) to abort
Just for the record, I'm running that pf_table patch for almost a month now
without any negative impact on my load balancers.
pfsync/carp/relayd
It also solved my problem with relayd.
However I believe some care should also be taken on relayd part
- do not check statistics on disabled redirects
- make redirect respect disabled table
I did posted some patches on tech@, don't know if they are ok but I do also run
them on my load balancers.
https://marc.info/?l=openbsd-tech=168859090917010=2
https://marc.info/?l=openbsd-tech=168899743827537=2
G
On 01/08/2023 02:50, Alexandr Nedvedicky wrote:
> Hello,
>
> the issue has been reported by Gianni Kapetanakis month ago [1]. It took
> several emails to figure out relayd(8) exists after hosts got disabled
> by 'relayctl host dis ...'
>
> The thing is that relayd(8) relies on pf(4) to create persistent
> tables (PFR_TFLAG_PERSIST) as relayd requests that:
>
> 47 void
> 48 init_tables(struct relayd *env)
> 49 {
> ...
> 62 TAILQ_FOREACH(rdr, env->sc_rdrs, entry) {
> 63 if (strlcpy(tables[i].pfrt_anchor, RELAYD_ANCHOR "/",
> 64 sizeof(tables[i].pfrt_anchor)) >= PF_ANCHOR_NAME_SIZE)
> 65 goto toolong;
> 66 if (strlcat(tables[i].pfrt_anchor, rdr->conf.name,
> 67 sizeof(tables[i].pfrt_anchor)) >= PF_ANCHOR_NAME_SIZE)
> 68 goto toolong;
> 69 if (strlcpy(tables[i].pfrt_name, rdr->conf.name,
> 70 sizeof(tables[i].pfrt_name)) >=
> 71 sizeof(tables[i].pfrt_name))
> 72 goto toolong;
> 73 tables[i].pfrt_flags |= PFR_TFLAG_PERSIST;
> 74 i++;
> 75 }
>
> unfortunately it's not the case as further investigation revealed [2].
>
> the issue can be easily reproduced by pfctl(8) which also creates
> persistent tables on behalf of command line:
>
> pfctl -t foo -T add ...
>
> command above always asks pf(4) to create persistent table, however
> pf(4) does not honor persistent flag when table exists already.
> One can verify that using commands as follows:
>
> ## create 'referenced' table only (table exists but has no active flag)
> # echo 'pass from in to any' |pfctl -f -
> # pfctl -sT -vg
> r-- foo
> # create instance of table using command line:
> # pfctl -t foo -T add 192.168.1.0/24
> 1/1 addresses added.
> # pfctl -sT -vg
> --a-r-- foo
> ## create instance of table , note the table will get 'p' flag
> # pfctl -t bar -T add 192.168.10.0/24
> 1 table created.
> 1/1 addresses added.
> # pfctl -sT -vg
> -pa bar
> --a-r-- foo
>
> one-liner change to sys/net/pf_table.c fixes that it also works for Gianni
> Kapetanakis. I'm also adding tests to regress/sys/net/pf_table/Makefile
> to cover it.
>
> On system which runs current the test fails with error as follows:
>
> pfctl -a regress/ttest -t instance -T add 192.168.1.0/24
> 1/1 addresses added.
> pfctl -a regress/ttest -sT -vg | diff table-persist.out -
> 1c1
> < -pa-r-- instanceregress/ttest
> ---
> > --a-r-- instanceregress/ttest
> *** Error 1 in . (Makefile:96 'flags')
> FAILED
>
> the failure is expected on system without patch. On system with
> patch applied all tests do pass.
>
> OK to commit?
>
> thanks and
> regards
> sashan
>
>
> [1] https://marc.info/?t=16881127045=1=2
>
> [2] https://marc.info/?l=openbsd-bugs=168868165801905=2
>
> 8<---8<---8<--8<
> diff --git a/sys/net/pf_table.c b/sys/net/pf_table.c
> index 6f23a6f795d..c862c804f84 100644
> --- a/sys/net/pf_table.c
> +++ b/sys/net/pf_table.c
> @@ -1565,8 +1565,10 @@ pfr_add_tables(struct pfr_table *tbl, int size, int
> *nadd, int flags)
> xadd++;
> } else if (!(flags & PFR_FLAG_DUMMY) &&
> !(p->pfrkt_flags & PFR_TFLAG_ACTIVE)) {
> - p->pfrkt_nflags = (p->pfrkt_flags &
> - ~PFR_TFLAG_USRMASK) | PFR_TFLAG_ACTIVE;
> + p->pfrkt_nflags =
> + (p->pfrkt_flags & ~PFR_TFLAG_USRMASK) |
> + (n->pfrkt_flags & PFR_TFLAG_USRMASK) |
> + PFR_TFLAG_ACTIVE;
> SLIST_INSERT_HEAD(, p, pfrkt_workq);
> }
> }
> diff --git a/regress/sys/net/pf_table/Makefile
> b/regress/sys/net/pf_table/Makefile
> index a71f0190c73..8911e8a1d35 100644
> --- a/regress/sys/net/pf_table/Makefile
> +++ b/regress/sys/net/pf_table/Makefile
> @@ -1,15 +1,26 @@
> #$OpenBSD: Makefile,v 1.3 2017/07/07 23:15:27 bluhm Exp $
>
> -REGRESS_TARGETS= hit miss cleanup
> -CLEANFILES= stamp-*
> +REGRESS_TARGETS= hit miss cleanup flags
> +CLEANFILES= stamp-* \
> + pf-reftab.conf \
>
Re: uvm_meter remove wakeup of swapper
On Tue, Aug 01, 2023 at 11:24:01AM +0200, Claudio Jeker wrote:
> Now that the issue in inteldrm was resolved we can finally remove this
> old wakeup of the swapper.
>
> OK?
ok mvs
> --
> :wq Claudio
>
> Index: uvm_meter.c
> ===
> RCS file: /cvs/src/sys/uvm/uvm_meter.c,v
> retrieving revision 1.44
> diff -u -p -r1.44 uvm_meter.c
> --- uvm_meter.c 21 Jun 2023 21:16:21 - 1.44
> +++ uvm_meter.c 1 Aug 2023 09:22:22 -
> @@ -82,15 +82,13 @@ void uvm_total(struct vmtotal *);
> void uvmexp_read(struct uvmexp *);
>
> /*
> - * uvm_meter: calculate load average and wake up the swapper (if needed)
> + * uvm_meter: calculate load average
> */
> void
> uvm_meter(void)
> {
> if ((gettime() % 5) == 0)
> uvm_loadav();
> - if (proc0.p_slptime > (maxslp / 2))
> - wakeup();
> }
>
> /*
>
uvm_meter remove wakeup of swapper
Now that the issue in inteldrm was resolved we can finally remove this
old wakeup of the swapper.
OK?
--
:wq Claudio
Index: uvm_meter.c
===
RCS file: /cvs/src/sys/uvm/uvm_meter.c,v
retrieving revision 1.44
diff -u -p -r1.44 uvm_meter.c
--- uvm_meter.c 21 Jun 2023 21:16:21 - 1.44
+++ uvm_meter.c 1 Aug 2023 09:22:22 -
@@ -82,15 +82,13 @@ void uvm_total(struct vmtotal *);
void uvmexp_read(struct uvmexp *);
/*
- * uvm_meter: calculate load average and wake up the swapper (if needed)
+ * uvm_meter: calculate load average
*/
void
uvm_meter(void)
{
if ((gettime() % 5) == 0)
uvm_loadav();
- if (proc0.p_slptime > (maxslp / 2))
- wakeup();
}
/*
Re: uvm_meter: remove wakeup of proc0
On Mon, Jul 31, 2023 at 08:31:41PM -0500, Scott Cheloha wrote:
> On Mon, Jul 31, 2023 at 10:04:44PM +0200, Claudio Jeker wrote:
> > On Mon, Jul 31, 2023 at 09:49:30PM +0200, Claudio Jeker wrote:
> > > On Mon, Jul 31, 2023 at 08:03:41PM +0300, Vitaliy Makkoveev wrote:
> > > > This is the culprit:
> > > >
> > > > schedule_timeout_uninterruptible(long timeout)
> > > > {
> > > > tsleep(curproc, PWAIT, "schtou", timeout);
> > > > return 0;
> > > > }
> > > >
> > >
> > > Please give this a try. I think on initialization
> > > intel_dp_wait_source_oui() is called before intel_dp->last_oui_write is
> > > set and this results in a 10min timeout because our jiffies are set to
> > > ULONG_MAX - (10 * 60 * HZ);
> >
> > After talking with kettenis@ I think the following diff is better.
> > Starting with 0 jiffies should fix this issue.
> > Unless we want to do the linux madness and set it to
> > ((unsigned long)(unsigned int) (-300*HZ))
> >
> > --
> > :wq Claudio
> >
> > Index: kern_clock.c
> > ===
> > RCS file: /cvs/src/sys/kern/kern_clock.c,v
> > retrieving revision 1.109
> > diff -u -p -r1.109 kern_clock.c
> > --- kern_clock.c25 Jul 2023 18:16:19 - 1.109
> > +++ kern_clock.c31 Jul 2023 20:01:57 -
> > @@ -84,7 +84,7 @@ int profhz;
> > intprofprocs;
> > intticks = INT_MAX - (15 * 60 * HZ);
> >
> > -volatile unsigned long jiffies = ULONG_MAX - (10 * 60 * HZ);
> > +volatile unsigned long jiffies;
> >
> > /*
> > * Initialize clock frequencies and start both clocks running.
> >
>
> I think this is backwards.
>
> Why are we changing the initial value of jiffies (wide) to resolve a
> problem with the initialization of one struct (narrow)? Changing the
> initial value of jiffies just masks the root cause.
>
> Isn't the right thing here to initialize the last-write timestamp when
> the struct is allocated?
This is all in code that is regularly synced with linux and so any local
change there is less then ideal. So it is better to alter the way jiffies
is initalized. jiffies is only there for drm so I don't think it is that
wide of a change.
Btw. on linux jiffies is initalized to:
#define INITIAL_JIFFIES ((unsigned long)(unsigned int) (-300*HZ))
and so the behaviour is different on 32 vs 64bit systems (which is the
worst possible default they could choose). So on the more common 64bit
systems the wrap around no longer happens early and bugs are introduced
because of this without anyone noticing.
Somebody could report this upstream since it is a bug in the intel drm
codebase.
--
:wq Claudio
