Re: 7.5 install crashes on "entry point at 0x1001000" HP Elitebook 840 G10
Hello, This is a link to a screenshot, I can't copy/paste at this step: https://ibb.co/tpr8zBz Thanks a lot ! Comete Le 24 mai 2024 20:38:45 GMT+02:00, Mike Larkin a écrit : >On Fri, May 24, 2024 at 06:59:24AM +, Comète wrote: >> Thanks Sven, >> >> I can't install OpenBDS because I get the error when trying to boot the >> install image. >> >> Comete >> > >At the boot> prompt, can you show what "mach mem" prints? > >Thanks > >-ml > >> 24 mai 2024 07:48 "Sven Wolf" a écrit: >> >> > Hi, >> > >> > I had a silimar issue on a Lenovo V130. >> > For this machine I needed to remove the amdgpu driver in the kernel. >> > >> > See also: >> > https://marc.info/?l=openbsd-misc=160232897421774=2 >> > https://marc.info/?l=openbsd-tech=160383074317608=2 >> > >> > Do you get the error "entry point at 0x1001000" also with the bsd.rd >> > kernel or only after you >> > installed the system with the bsd.mp/bsd.sp kernel? >> > >> > Best regards, >> > Sven >> > >> > On 5/23/24 22:40, Comète wrote: >> > >> >> Hello, >> >> I tried to install OpenBSD 7.5 on a new HP Elitebook 840 G10 (UEFI >> >> capable only) without success. >> >> It is stuck at boot on "entry point at 0x1001000". >> >> Even retried after a BIOS upgrade but no luck either. >> >> I tried with a snapshot install too with the same result. >> >> I post here what lspci returns from a debian bookworm: >> >> 00:00.0 Host bridge: Intel Corporation Device a706 >> >> 00:02.0 VGA compatible controller: Intel Corporation Raptor Lake-P [Iris >> >> Xe Graphics] (rev 04) >> >> 00:04.0 Signal processing controller: Intel Corporation Raptor Lake >> >> Dynamic Platform and Thermal >> >> Framework Processor Participant >> >> 00:06.0 PCI bridge: Intel Corporation Raptor Lake PCIe 4.0 Graphics Port >> >> 00:06.2 PCI bridge: Intel Corporation Device a73d >> >> 00:07.0 PCI bridge: Intel Corporation Raptor Lake-P Thunderbolt 4 PCI >> >> Express Root Port >> >> 00:07.2 PCI bridge: Intel Corporation Raptor Lake-P Thunderbolt 4 PCI >> >> Express Root Port >> >> 00:08.0 System peripheral: Intel Corporation GNA Scoring Accelerator >> >> module >> >> 00:0a.0 Signal processing controller: Intel Corporation Raptor Lake >> >> Crashlog and Telemetry (rev 01) >> >> 00:0d.0 USB controller: Intel Corporation Raptor Lake-P Thunderbolt 4 USB >> >> Controller >> >> 00:0d.2 USB controller: Intel Corporation Raptor Lake-P Thunderbolt 4 NHI >> >> 00:0d.3 USB controller: Intel Corporation Raptor Lake-P Thunderbolt 4 NHI >> >> 00:14.0 USB controller: Intel Corporation Alder Lake PCH USB 3.2 xHCI >> >> Host Controller (rev 01) >> >> 00:14.2 RAM memory: Intel Corporation Alder Lake PCH Shared SRAM (rev 01) >> >> 00:14.3 Network controller: Intel Corporation Raptor Lake PCH CNVi WiFi >> >> (rev 01) >> >> 00:15.0 Serial bus controller: Intel Corporation Alder Lake PCH Serial IO >> >> I2C Controller #0 (rev >> >> 01) >> >> 00:16.0 Communication controller: Intel Corporation Alder Lake PCH HECI >> >> Controller (rev 01) >> >> 00:16.3 Serial controller: Intel Corporation Alder Lake AMT SOL >> >> Redirection (rev 01) >> >> 00:1c.0 PCI bridge: Intel Corporation Alder Lake PCH-P PCI Express Root >> >> Port #9 (rev 01) >> >> 00:1e.0 Communication controller: Intel Corporation Alder Lake PCH UART >> >> #0 (rev 01) >> >> 00:1e.2 Serial bus controller: Intel Corporation Alder Lake SPI >> >> Controller (rev 01) >> >> 00:1f.0 ISA bridge: Intel Corporation Raptor Lake LPC/eSPI Controller >> >> (rev 01) >> >> 00:1f.3 Multimedia audio controller: Intel Corporation Raptor Lake-P/U/H >> >> cAVS (rev 01) >> >> 00:1f.4 SMBus: Intel Corporation Alder Lake PCH-P SMBus Host Controller >> >> (rev 01) >> >> 00:1f.5 Serial bus controller: Intel Corporation Alder Lake-P PCH SPI >> >> Controller (rev 01) >> >> 02:00.0 Non-Volatile memory controller: SK hynix BC901 NVMe Solid State >> >> Drive (DRAM-less) (rev 03) >> >> 57:00.0 Wireless controller [0d40]: Intel Corporation XMM7560 LTE >> >> Advanced Pro Modem (rev 01) >> >>> Thanks for your help. >> >> Comete >> -- Envoyé de mon téléphone. Excusez la brièveté.
znc webadmin module V 7.4 and 7.5
Hello i was using znc on OpenBSD 7.4 and it worked correctly, then i did a clean installation of 7.5 and znc does not create the webadmin page, irssi said that webadmin module is loaded! Then i went back to 7.4 and it has the exact same behaviour. Tested adding LoadModule webadmin at znc.conf and it failed. i went to znc irc channel and they said that it could be the OpenBSD package. Could somebody help please? Thanks misc
Re: wifi
Is there plan to add support ? Thanks a lot Em qui., 23 de mai. de 2024 às 04:10, Otto Moerbeek escreveu: > On Thu, May 23, 2024 at 03:56:01AM -0300, Gustavo Rios wrote: > > > Here you have them: > > ... > "Realtek 8821CE" rev 0x00 at pci2 dev 0 function 0 not configured > > That means there is no driver available in OpenBSD for that card. > > -Otto > -- The lion and the tiger may be more powerful, but the wolves do not perform in the circus
Re: Sudden reboot every 5-10 minutes on latest snapshot
Alexandre Ratchov wrote:
> On Fri, May 24, 2024 at 04:30:52PM +, Ali Farzanrad wrote:
> > Hi again,
> >
> > During my tests it seems that this version of kernel works fine:
> >
> > # TZ=UTC cvs -Qd /cvs get -D "2024-05-17 19:30" -P src
> >
> > But this version of kernel will cause sudden reboots without any kernel
> > panic or message after 5-60 minutes in my Minisforum UM790:
> >
> > # TZ=UTC cvs -Qd /cvs get -D "2024-05-17 20:00" -P src
> >
> > After investigation I found this patch could fix my problem:
> >
> > Index: azalia.c
> > ===
> > RCS file: /home/cvs/src/sys/dev/pci/azalia.c,v
> > diff -u -p -r1.287 azalia.c
> > --- azalia.c17 May 2024 19:43:45 - 1.287
> > +++ azalia.c24 May 2024 16:26:38 -
> > @@ -557,6 +557,16 @@ azalia_pci_attach(struct device *parent,
> > azalia_pci_write(sc->pc, sc->tag, ICH_PCI_MMC, reg);
> > }
> >
> > + /* disable MSI for AMD Summit Ridge/Raven Ridge HD Audio */
> > + if (PCI_VENDOR(sc->pciid) == PCI_VENDOR_AMD) {
> > + switch (PCI_PRODUCT(sc->pciid)) {
> > + case PCI_PRODUCT_AMD_17_HDA:
> > + case PCI_PRODUCT_AMD_17_1X_HDA:
> > + case PCI_PRODUCT_AMD_HUDSON2_HDA:
> > + pa->pa_flags &= ~PCI_FLAGS_MSI_ENABLED;
> > + }
> > + }
> > +
> > /* interrupt */
> > if (pci_intr_map_msi(pa, ) && pci_intr_map(pa, )) {
> > printf(": can't map interrupt\n");
> >
> > However it breaks my front 3.5mm audio port and I should use my
> > USB-to-3.5mm audio port adapter again.
> >
> > How may I investigate more?
> >
>
> could you confirm that the system reboots only while you're using the
> azalia device?
I disabled sndiod, and unplugged my USB-to-3.5mm audio adapter and also
unplugged front 3.5mm audio port, then reboot my OpenBSD and waited on
xenodm login screen for few minutes; most of the time it reboots in
less than 10 minutes... without any interaction from me, or playing
anything...
> when you apply above diff, is audio unstable or it doesn't work at
> all?
It doesn't work at all. No input, no output. Even sndioctl will
freeze.
However when I plug my USB-to-3.5mm audio adapter, and run sndiod with
these arguments: -f rsnd/0 -F rsnd/1
I have audio output. However I don't have audio input for such a long
time, maybe 2 months (if it could help I can search for latest version
of kernel which my mic works with USB-to-3.5mm audio adapter).
With latest kernel front 3.5mm audio port works great, both as input and
as output; the only problem that I have with it is sudden reboots :(
Re: 7.5 install crashes on "entry point at 0x1001000" HP Elitebook 840 G10
On Fri, May 24, 2024 at 06:59:24AM +, Comète wrote: > Thanks Sven, > > I can't install OpenBDS because I get the error when trying to boot the > install image. > > Comete > At the boot> prompt, can you show what "mach mem" prints? Thanks -ml > 24 mai 2024 07:48 "Sven Wolf" a écrit: > > > Hi, > > > > I had a silimar issue on a Lenovo V130. > > For this machine I needed to remove the amdgpu driver in the kernel. > > > > See also: > > https://marc.info/?l=openbsd-misc=160232897421774=2 > > https://marc.info/?l=openbsd-tech=160383074317608=2 > > > > Do you get the error "entry point at 0x1001000" also with the bsd.rd kernel > > or only after you > > installed the system with the bsd.mp/bsd.sp kernel? > > > > Best regards, > > Sven > > > > On 5/23/24 22:40, Comète wrote: > > > >> Hello, > >> I tried to install OpenBSD 7.5 on a new HP Elitebook 840 G10 (UEFI capable > >> only) without success. > >> It is stuck at boot on "entry point at 0x1001000". > >> Even retried after a BIOS upgrade but no luck either. > >> I tried with a snapshot install too with the same result. > >> I post here what lspci returns from a debian bookworm: > >> 00:00.0 Host bridge: Intel Corporation Device a706 > >> 00:02.0 VGA compatible controller: Intel Corporation Raptor Lake-P [Iris > >> Xe Graphics] (rev 04) > >> 00:04.0 Signal processing controller: Intel Corporation Raptor Lake > >> Dynamic Platform and Thermal > >> Framework Processor Participant > >> 00:06.0 PCI bridge: Intel Corporation Raptor Lake PCIe 4.0 Graphics Port > >> 00:06.2 PCI bridge: Intel Corporation Device a73d > >> 00:07.0 PCI bridge: Intel Corporation Raptor Lake-P Thunderbolt 4 PCI > >> Express Root Port > >> 00:07.2 PCI bridge: Intel Corporation Raptor Lake-P Thunderbolt 4 PCI > >> Express Root Port > >> 00:08.0 System peripheral: Intel Corporation GNA Scoring Accelerator module > >> 00:0a.0 Signal processing controller: Intel Corporation Raptor Lake > >> Crashlog and Telemetry (rev 01) > >> 00:0d.0 USB controller: Intel Corporation Raptor Lake-P Thunderbolt 4 USB > >> Controller > >> 00:0d.2 USB controller: Intel Corporation Raptor Lake-P Thunderbolt 4 NHI > >> 00:0d.3 USB controller: Intel Corporation Raptor Lake-P Thunderbolt 4 NHI > >> 00:14.0 USB controller: Intel Corporation Alder Lake PCH USB 3.2 xHCI Host > >> Controller (rev 01) > >> 00:14.2 RAM memory: Intel Corporation Alder Lake PCH Shared SRAM (rev 01) > >> 00:14.3 Network controller: Intel Corporation Raptor Lake PCH CNVi WiFi > >> (rev 01) > >> 00:15.0 Serial bus controller: Intel Corporation Alder Lake PCH Serial IO > >> I2C Controller #0 (rev > >> 01) > >> 00:16.0 Communication controller: Intel Corporation Alder Lake PCH HECI > >> Controller (rev 01) > >> 00:16.3 Serial controller: Intel Corporation Alder Lake AMT SOL > >> Redirection (rev 01) > >> 00:1c.0 PCI bridge: Intel Corporation Alder Lake PCH-P PCI Express Root > >> Port #9 (rev 01) > >> 00:1e.0 Communication controller: Intel Corporation Alder Lake PCH UART #0 > >> (rev 01) > >> 00:1e.2 Serial bus controller: Intel Corporation Alder Lake SPI Controller > >> (rev 01) > >> 00:1f.0 ISA bridge: Intel Corporation Raptor Lake LPC/eSPI Controller (rev > >> 01) > >> 00:1f.3 Multimedia audio controller: Intel Corporation Raptor Lake-P/U/H > >> cAVS (rev 01) > >> 00:1f.4 SMBus: Intel Corporation Alder Lake PCH-P SMBus Host Controller > >> (rev 01) > >> 00:1f.5 Serial bus controller: Intel Corporation Alder Lake-P PCH SPI > >> Controller (rev 01) > >> 02:00.0 Non-Volatile memory controller: SK hynix BC901 NVMe Solid State > >> Drive (DRAM-less) (rev 03) > >> 57:00.0 Wireless controller [0d40]: Intel Corporation XMM7560 LTE Advanced > >> Pro Modem (rev 01) > >>> Thanks for your help. > >> Comete >
Re: Q: Problems forwarding traffic using pf ...
On Fri, May 24, 2024 at 06:04:25PM +0200, Peter N. M. Hansteen wrote: > On Thu, May 23, 2024 at 11:14:20AM +0200, Why 42? The lists account. wrote: > > pfctl reports: > > # pfctl -vvs rules | grep @ > > @0 block return log all > > @1 pass in log on em0 inet proto udp from 192.168.178.166 to any tag UDP > > @2 pass out log on ure0 all flags S/SA tagged UDP Why setting "flags S/SA" on a rule meant for UDP packets? > > > > I see that rule 1 is matched, but never rule 2. E.g. > > ... > > May 23 10:32:06.602759 rule 0/(match) block in on em0: 192.168.178.179.5353 > > > 224.0.0.251.5353: 46[|domain] (DF) > > May 23 10:32:06.603963 rule 0/(match) block in on em0: > > fe80::4434:8bff:fecd:b116.5353 > ff02::fb.5353: 46[|domain] [flowlabel > > 0xbaff9] > > May 23 10:32:09.700212 rule 0/(match) block in on em0: 192.168.178.254 > > > 224.0.0.1: igmp query [len 12] (DF) [tos 0xc0] [ttl 1] > > May 23 10:32:13.267374 rule 1/(match) pass in on em0: 192.168.178.166.56334 > > > 192.168.178.11.54321: udp 7 > > So this last one never leaves, right? > > what does the gateway's routing table say about how to reach the destination > network? > > also relevant, what is the configuration of the interfaces involved? > > I'm thinking this could be down to using RFC1918 addresses and not being > extra careful > about netmasks and routes, but we need more info on the actual configuration > to be sure. > > - Peter > > -- > Peter N. M. Hansteen, member of the first RFC 1149 implementation team > https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/ > "Remember to set the evil bit on all malicious network traffic" > delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. > --
Re: Sudden reboot every 5-10 minutes on latest snapshot
On Fri, May 24, 2024 at 04:30:52PM +, Ali Farzanrad wrote:
> Hi again,
>
> During my tests it seems that this version of kernel works fine:
>
> # TZ=UTC cvs -Qd /cvs get -D "2024-05-17 19:30" -P src
>
> But this version of kernel will cause sudden reboots without any kernel
> panic or message after 5-60 minutes in my Minisforum UM790:
>
> # TZ=UTC cvs -Qd /cvs get -D "2024-05-17 20:00" -P src
>
> After investigation I found this patch could fix my problem:
>
> Index: azalia.c
> ===
> RCS file: /home/cvs/src/sys/dev/pci/azalia.c,v
> diff -u -p -r1.287 azalia.c
> --- azalia.c 17 May 2024 19:43:45 - 1.287
> +++ azalia.c 24 May 2024 16:26:38 -
> @@ -557,6 +557,16 @@ azalia_pci_attach(struct device *parent,
> azalia_pci_write(sc->pc, sc->tag, ICH_PCI_MMC, reg);
> }
>
> + /* disable MSI for AMD Summit Ridge/Raven Ridge HD Audio */
> + if (PCI_VENDOR(sc->pciid) == PCI_VENDOR_AMD) {
> + switch (PCI_PRODUCT(sc->pciid)) {
> + case PCI_PRODUCT_AMD_17_HDA:
> + case PCI_PRODUCT_AMD_17_1X_HDA:
> + case PCI_PRODUCT_AMD_HUDSON2_HDA:
> + pa->pa_flags &= ~PCI_FLAGS_MSI_ENABLED;
> + }
> + }
> +
> /* interrupt */
> if (pci_intr_map_msi(pa, ) && pci_intr_map(pa, )) {
> printf(": can't map interrupt\n");
>
> However it breaks my front 3.5mm audio port and I should use my
> USB-to-3.5mm audio port adapter again.
>
> How may I investigate more?
>
could you confirm that the system reboots only while you're using the
azalia device?
when you apply above diff, is audio unstable or it doesn't work at
all?
Re: Sudden reboot every 5-10 minutes on latest snapshot
Hi again,
During my tests it seems that this version of kernel works fine:
# TZ=UTC cvs -Qd /cvs get -D "2024-05-17 19:30" -P src
But this version of kernel will cause sudden reboots without any kernel
panic or message after 5-60 minutes in my Minisforum UM790:
# TZ=UTC cvs -Qd /cvs get -D "2024-05-17 20:00" -P src
After investigation I found this patch could fix my problem:
Index: azalia.c
===
RCS file: /home/cvs/src/sys/dev/pci/azalia.c,v
diff -u -p -r1.287 azalia.c
--- azalia.c17 May 2024 19:43:45 - 1.287
+++ azalia.c24 May 2024 16:26:38 -
@@ -557,6 +557,16 @@ azalia_pci_attach(struct device *parent,
azalia_pci_write(sc->pc, sc->tag, ICH_PCI_MMC, reg);
}
+ /* disable MSI for AMD Summit Ridge/Raven Ridge HD Audio */
+ if (PCI_VENDOR(sc->pciid) == PCI_VENDOR_AMD) {
+ switch (PCI_PRODUCT(sc->pciid)) {
+ case PCI_PRODUCT_AMD_17_HDA:
+ case PCI_PRODUCT_AMD_17_1X_HDA:
+ case PCI_PRODUCT_AMD_HUDSON2_HDA:
+ pa->pa_flags &= ~PCI_FLAGS_MSI_ENABLED;
+ }
+ }
+
/* interrupt */
if (pci_intr_map_msi(pa, ) && pci_intr_map(pa, )) {
printf(": can't map interrupt\n");
However it breaks my front 3.5mm audio port and I should use my
USB-to-3.5mm audio port adapter again.
How may I investigate more?
> > > > My Minisforum UM790 keeps reboot every 5-10 minutes, without any Kernel
> > > > Panic or visible message how may I debug it?
> > > > I'm using latest OpenBSD snapshot with this amd64/BUILDINFO:
> > > > Build date: 1716424636 - Thu May 23 00:37:16 UTC 2024
> > >
> > > Not a lot to go on really.
> > >
> > > Is the machine doing anything or just idle?
> >
> > It get reboot even in xenodm login screen without any interaction from me.
> >
> > > Is X running?
> >
> > It's funny. I disabled the xenodm and it lived for more than 10 minutes;
> > then I enabled and started xenodm and it suddenly rebooted after few
> > minutes!
> >
> > Next time I keep xenodm running, but switched to ttyC0 terminal using
> > Alt+Ctrl+F1 key and it lived for more than 10 minutes; then I just
> > switched to Xorg using Alt+Ctrl+F5 and it suddenly rebooted again after
> > few minutes!
> >
> > > Do you get the same with 7.5? if yes, try older releases - can you
> > > find one where it doesn't happen?
> >
> > I rarely got same issue in previous snapshots (I think my last snapshot
> > was for 6 days ago and I had no serious issue with that).
> >
> > I think I sould compile and test previous versions of xenocara, right?
>
> Try with just an older kernel first and leave userland alone.
> ftp.hostserver.de and openbsd.cs.toronto.edu both have some old
> snaps in /archive. (If no snap was built on a certain day then
> the files will be identical in the archive so no point testing
> when there was no change - you can use what(1) to show the
> version - I'd save a few under names like /bsd.mp.
> and type "boot bsd.mp." at the boot loader).
>
>
> > > >
> > > > # (dmesg; sysctl hw.sensors)
> > > > OpenBSD 7.5-current (GENERIC.MP) #78: Wed May 22 18:31:14 MDT 2024
> > > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > > > real mem = 31909883904 (30431MB)
> > > > avail mem = 30921310208 (29488MB)
> > > > random: good seed from bootblocks
> > > > mpath0 at root
> > > > scsibus0 at mpath0: 256 targets
> > > > mainbus0 at root
> > > > bios0 at mainbus0: SMBIOS rev. 3.5 @ 0x9ab7f000 (45 entries)
> > > > bios0: vendor American Megatrends International, LLC. version "1.01"
> > > > date 06/05/2023
> > > > bios0: Micro Computer (HK) Tech Limited F7BSC
> > > > efi0 at bios0: UEFI 2.8
> > > > efi0: American Megatrends rev 0x5001d
> > > > acpi0 at bios0: ACPI 6.4
> > > > acpi0: sleep states S0 S4 S5
> > > > acpi0: tables DSDT FACP SSDT SSDT FIDT MCFG FPDT VFCT BGRT TPM2 SSDT
> > > > CRAT CDIT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT WSMT APIC IVRS
> > > > SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT
> > > > acpi0: wakeup devices GPP1(S4) GPP0(S4) GPP5(S4) GPP7(S4) GP11(S4)
> > > > SWUS(S4) GP12(S4) SWUS(S4)
> > > > acpitimer0 at acpi0: 3579545 Hz, 32 bits
> > > > acpimcfg0 at acpi0
> > > > acpimcfg0: addr 0xe000, bus 0-255
> > > > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> > > > cpu0 at mainbus0: apid 0 (boot processor)
> > > > cpu0: AMD Ryzen 9 7940HS w/ Radeon 780M Graphics, 4000.00 MHz,
> > > > 19-74-01, patch 0a704101
> > > > cpu0: cpuid 1
> > > > edx=178bfbff
> > > >
> > > > ecx=76f8320b
> > > > cpu0: cpuid 6 eax=4 ecx=1
> > > > cpu0: cpuid 7.0
> > > > ebx=f1bf97a9
> > > > ecx=405fce edx=1000
> > > > cpu0: cpuid d.1 eax=f
> > > > cpu0: cpuid 8001 edx=2fd3fbff
> > > > ecx=75c237ff
> > > > cpu0: cpuid 8007 edx=e799
> > > > cpu0: cpuid 8008
> > > > ebx=791ef257
> > > > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way
Re: Q: Problems forwarding traffic using pf ...
On Thu, May 23, 2024 at 11:14:20AM +0200, Why 42? The lists account. wrote: > pfctl reports: > # pfctl -vvs rules | grep @ > @0 block return log all > @1 pass in log on em0 inet proto udp from 192.168.178.166 to any tag UDP > @2 pass out log on ure0 all flags S/SA tagged UDP > > I see that rule 1 is matched, but never rule 2. E.g. > ... > May 23 10:32:06.602759 rule 0/(match) block in on em0: 192.168.178.179.5353 > > 224.0.0.251.5353: 46[|domain] (DF) > May 23 10:32:06.603963 rule 0/(match) block in on em0: > fe80::4434:8bff:fecd:b116.5353 > ff02::fb.5353: 46[|domain] [flowlabel > 0xbaff9] > May 23 10:32:09.700212 rule 0/(match) block in on em0: 192.168.178.254 > > 224.0.0.1: igmp query [len 12] (DF) [tos 0xc0] [ttl 1] > May 23 10:32:13.267374 rule 1/(match) pass in on em0: 192.168.178.166.56334 > > 192.168.178.11.54321: udp 7 So this last one never leaves, right? what does the gateway's routing table say about how to reach the destination network? also relevant, what is the configuration of the interfaces involved? I'm thinking this could be down to using RFC1918 addresses and not being extra careful about netmasks and routes, but we need more info on the actual configuration to be sure. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: OpenBSD 7.4 in virtualize env
> Sometimes, rarely, across multiple version ( did not see it in 7.5 so far ) > the log `scsi_xfer pool exhausted` just get spammed forever, > > It doesn't crash, the device just spam the message , so it s active > > I do not have a way to create the problem , but, > i wonder if the code could be modified so the device just drop to DDB >Did you run out of memory / swap perhaps? I have noticed that occurring when my system runs out of swap space. -- jrmu IRCNow (https://ircnow.org) signature.asc Description: PGP signature
Re: OpenBSD 7.4 in virtualize env
On 2024-05-24, Sven F. wrote: > --c4123906193364e5 > Content-Type: text/plain; charset="UTF-8" > > Hello, > > Sometimes, rarely, across multiple version ( did not see it in 7.5 so far ) > the log `scsi_xfer pool exhausted` just get spammed forever, > > It doesn't crash, the device just spam the message , so it s active > > I do not have a way to create the problem , but, > i wonder if the code could be modified so the device just drop to DDB It can, just change the printf to panic. /sys/scsi/scsi_base.c r1.283 fixed the main thing triggering that problem, but it was already committed before 7.4
OpenBSD 7.4 in virtualize env
Hello, Sometimes, rarely, across multiple version ( did not see it in 7.5 so far ) the log `scsi_xfer pool exhausted` just get spammed forever, It doesn't crash, the device just spam the message , so it s active I do not have a way to create the problem , but, i wonder if the code could be modified so the device just drop to DDB something like if this pool is exhausted for "longtime" just crash (or reboot if sysctl is configured that way ) ``` bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf68b0 (9 entries) bios0: vendor SeaBIOS version "2:1.10.2-58953eb7" date 04/01/2014 bios0: OpenStack Foundation OpenStack Nova ... vioscsi0 at virtio1: qsize 128 scsibus1 at vioscsi0: 255 targets sd0 at scsibus1 targ 0 lun 0: ``` I will upgrade to 7.5 soon anyway Best.
Re: Q: Problems forwarding traffic using pf ...
Hi Guys, Thanks for the feedback, to address your points: 1> Possibly stupid question, but did you set the sysctl(s) to enable forwarding? Yes I tried this pf rule change with version 4 forwarding (net.inet.ip.forwarding) both enabled and disabled. Either way the pf "pass out tagged" rule is never matched. I didn't reboot after changing this setting. It's not clear to me if that is necessary. For the version 6 variable (net.inet6.ip6.forwarding) "man 2 sysctl" states: "... changing this variable during operation may cause serious trouble. Hence, this variable should only be set at bootstrap time." Whatever that might mean. Anyway, for the version 4 variable there no similar remark. 2> And there is also mforwarding 3> And multicast=YES rc.conf.local In this first simple proof/test I just tried to forward some UDP. So this is not yet relevant. But I think you are both right, if I get as far as doing multicasting, I'll probably need those. Out of interest I grepped in /etc and it seems that setting multicast=YES influences the netstart script. When multicast is not "YES" then the route for 224.0.0.0/4 is deleted and re-added to the IP loopback address with an option "reject". Cheers, Robb.
Re: unknown USB vendor
Probably https://wikidevi.wi-cat.ru/AMPAK_AP6212 Peter J. Philipp írta 2024. máj.. 24, P-n 11:39 órakor: > Hi, > > I got a "are you a human?" on google so I switched to qwant.com for > searching > but the search is not as good. I'm looking for the USB vendor of this > USB > vendor id. 0x02d0, and the device id is 0xa9a6. Afaict this is a > ure(4) > device with a builtin usb hub. But there is no other markings on the > outside, related to manufacturer. It does not get detected by default > on an April > kernel code. It does have a micro-USB cable for the raspberry pi zero > 2 that > I wanted to use this with. > > Anyone have any details on these vendor and device id's? > > Best Regards, > -pjp > > -- > ** all info about me: lynx https://callpeter.tel, dig loc delphinusdns.org ** -- --Z--
unknown USB vendor
Hi, I got a "are you a human?" on google so I switched to qwant.com for searching but the search is not as good. I'm looking for the USB vendor of this USB vendor id. 0x02d0, and the device id is 0xa9a6. Afaict this is a ure(4) device with a builtin usb hub. But there is no other markings on the outside, related to manufacturer. It does not get detected by default on an April kernel code. It does have a micro-USB cable for the raspberry pi zero 2 that I wanted to use this with. Anyone have any details on these vendor and device id's? Best Regards, -pjp -- ** all info about me: lynx https://callpeter.tel, dig loc delphinusdns.org **
Re: 7.5 install crashes on "entry point at 0x1001000" HP Elitebook 840 G10
Thanks Sven, I can't install OpenBDS because I get the error when trying to boot the install image. Comete 24 mai 2024 07:48 "Sven Wolf" a écrit: > Hi, > > I had a silimar issue on a Lenovo V130. > For this machine I needed to remove the amdgpu driver in the kernel. > > See also: > https://marc.info/?l=openbsd-misc=160232897421774=2 > https://marc.info/?l=openbsd-tech=160383074317608=2 > > Do you get the error "entry point at 0x1001000" also with the bsd.rd kernel > or only after you > installed the system with the bsd.mp/bsd.sp kernel? > > Best regards, > Sven > > On 5/23/24 22:40, Comète wrote: > >> Hello, >> I tried to install OpenBSD 7.5 on a new HP Elitebook 840 G10 (UEFI capable >> only) without success. >> It is stuck at boot on "entry point at 0x1001000". >> Even retried after a BIOS upgrade but no luck either. >> I tried with a snapshot install too with the same result. >> I post here what lspci returns from a debian bookworm: >> 00:00.0 Host bridge: Intel Corporation Device a706 >> 00:02.0 VGA compatible controller: Intel Corporation Raptor Lake-P [Iris Xe >> Graphics] (rev 04) >> 00:04.0 Signal processing controller: Intel Corporation Raptor Lake Dynamic >> Platform and Thermal >> Framework Processor Participant >> 00:06.0 PCI bridge: Intel Corporation Raptor Lake PCIe 4.0 Graphics Port >> 00:06.2 PCI bridge: Intel Corporation Device a73d >> 00:07.0 PCI bridge: Intel Corporation Raptor Lake-P Thunderbolt 4 PCI >> Express Root Port >> 00:07.2 PCI bridge: Intel Corporation Raptor Lake-P Thunderbolt 4 PCI >> Express Root Port >> 00:08.0 System peripheral: Intel Corporation GNA Scoring Accelerator module >> 00:0a.0 Signal processing controller: Intel Corporation Raptor Lake Crashlog >> and Telemetry (rev 01) >> 00:0d.0 USB controller: Intel Corporation Raptor Lake-P Thunderbolt 4 USB >> Controller >> 00:0d.2 USB controller: Intel Corporation Raptor Lake-P Thunderbolt 4 NHI >> 00:0d.3 USB controller: Intel Corporation Raptor Lake-P Thunderbolt 4 NHI >> 00:14.0 USB controller: Intel Corporation Alder Lake PCH USB 3.2 xHCI Host >> Controller (rev 01) >> 00:14.2 RAM memory: Intel Corporation Alder Lake PCH Shared SRAM (rev 01) >> 00:14.3 Network controller: Intel Corporation Raptor Lake PCH CNVi WiFi (rev >> 01) >> 00:15.0 Serial bus controller: Intel Corporation Alder Lake PCH Serial IO >> I2C Controller #0 (rev >> 01) >> 00:16.0 Communication controller: Intel Corporation Alder Lake PCH HECI >> Controller (rev 01) >> 00:16.3 Serial controller: Intel Corporation Alder Lake AMT SOL Redirection >> (rev 01) >> 00:1c.0 PCI bridge: Intel Corporation Alder Lake PCH-P PCI Express Root Port >> #9 (rev 01) >> 00:1e.0 Communication controller: Intel Corporation Alder Lake PCH UART #0 >> (rev 01) >> 00:1e.2 Serial bus controller: Intel Corporation Alder Lake SPI Controller >> (rev 01) >> 00:1f.0 ISA bridge: Intel Corporation Raptor Lake LPC/eSPI Controller (rev >> 01) >> 00:1f.3 Multimedia audio controller: Intel Corporation Raptor Lake-P/U/H >> cAVS (rev 01) >> 00:1f.4 SMBus: Intel Corporation Alder Lake PCH-P SMBus Host Controller (rev >> 01) >> 00:1f.5 Serial bus controller: Intel Corporation Alder Lake-P PCH SPI >> Controller (rev 01) >> 02:00.0 Non-Volatile memory controller: SK hynix BC901 NVMe Solid State >> Drive (DRAM-less) (rev 03) >> 57:00.0 Wireless controller [0d40]: Intel Corporation XMM7560 LTE Advanced >> Pro Modem (rev 01) >>> Thanks for your help. >> Comete
custom syspatch
Suppose I want to add a custom patch to a release system (backport patch from
current and compile on release),
but keep the system able to load more official syspatches:
is it enough to put the relevant new object file (say pf.o) in
/usr/share/relink/kernel/GENERIC.MP/
and just do reorder_kernel?
The new object will come from manually compiling release sources kernel with
specific patch backported from current (on another machine).
I took for example syspatch74-009_pf.tgz
Apart from the pf.o I also see vers.o and gap.o
Should I also provide a new gap.o? I don't understand what this does.
In Makefile I see
newbsd:
${MAKE_GAP}
${SYSTEM_LD_HEAD}
${SYSTEM_LD} swapgeneric.o
${SYSTEM_LD_TAIL}
rm -f bsd.gdb
mv -f newbsd bsd
so makegap.sh is run from ${MAKE_GAP} which seems to provide a new gap.o
Thanks,
G
