7.1 sparc64 softraid0 1.5TB/2TB partition limit of RAID 5 + c
Hi,
I was attempting to have a RAID 5 softraid0 setup on a sparc64 machine
(boot log output below) but ran into problems when attempting to create
a single partition with the size 5.5TB (RAID 5 with 4 x 2TB hard
drives). I found an interesting problem when using disklabel on the
softraid0 hard drive device, when attempting to make this 5.5TB
partition. The partition "a" would only be allowed as 1.5TB and any
partition >= "d" would only be allowed as 2TB, however the limit
occurred silently after disklabel had exited. When inside disklabel, I
could allocate a single "a" partition to be 5.5TB successfully and was
able to write the partition successfully. However, when the disklabel
process exited, either with the q command or a kill signal 9, the
partition would be shrunk to the limit described above. If the
disklabel process was suspended (ctrl-Z), this wouldn't happen and newfs
would see the 5.5TB partition, though usage of the partition wouldn't
work. The partition would have inaccessible blocks that fsck showed
extreme anger at, when it saw it at boot time.
I did bump into a kernel panic when doing the sequence (kernel panic
output is below the boot log): disklabel single partition 5.5TB written,
suspend disklabel process, newfs on partition, kill -9 disklabel
process, write a single file to the filesystem ("the_first_file" in the
command line output below).
The 1.5TB/2TB partition limit is known and expected on sparc64, isn't
it? I didn't see the limit mentioned in documentation, though the
disklabel manpage does say "On some machines, such as Sparc64, partition
tables may not exhibit the full functionality described above.". I
bumped into the same limit when attempting to use softraid0 RAID c too.
Tell me if you need more information.
Best Regards,
Michael
SPARC Enterprise T5220, No Keyboard
Copyright (c) 1998, 2017, Oracle and/or its affiliates. All rights reserved.
OpenBoot 4.33.6.h, 65408 MB memory available, Serial #89737534.
Ethernet address 0:21:28:59:49:3e, Host ID: 8559493e.
Boot device: disk0 File and args: sr0a:/bsd
OpenBSD IEEE 1275 Bootblock 2.1
>> OpenBSD BOOT 1.22
ERROR: /iscsi-hba: No iscsi-network-bootpath property
sr0*
|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#Booting sr0:a/bsd
10060280@0x100|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#+7688@0x19981f8|#+170388@0x1c0/#-#\#|#/#-#\#|#/#-#\#+4023916@0x1c29994|#
/#symbols @ 0xfe93a400
484557-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#+165+654072/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#+452627|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#
start=0x100
[ using 1592456 bytes of bsd ELF symbol table ]
console is /virtual-devices@100/console@1
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2022 OpenBSD. All rights reserved.
https://www.OpenBSD.org
OpenBSD 7.1 (GENERIC.MP) #1269: Mon Apr 11 22:05:10 MDT 2022
dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/GENERIC.MP
real mem = 68585259008 (65408MB)
avail mem = 67369304064 (64248MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root: SPARC Enterprise T5220
cpu0 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu1 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu2 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu3 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu4 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu5 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu6 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu7 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
cpu8 at mainbus0:
Re: drm makes X crash (only with modesetting)
On Sep 16 2022, Walter Alejandro Iglesias wrote: > It happens with modesetting driver only, NOT with intel. I was wrong with this. Now it happened with intel (SNA), it just took more time.
Re: drm makes X crash (only with modesetting)
On Sep 16 2022, Jonathan Gray wrote: > On Fri, Sep 16, 2022 at 01:55:13PM +0200, Walter Alejandro Iglesias wrote: > > Hello everone, > > > > After upgrading to the latest snapshot I'm experiencing something > > similar to what's described here: > > What snapshot were you running before? Unfortunately, I can tell you exactly which snapshot the issue came with, since lately I've been using cwm(1), it was today that I changed back to fvwm2 that I found the problem. The only I can tell you for sure is that under this snapshot: OpenBSD 7.2-beta (GENERIC.MP) #707: Wed Aug 24 10:03:37 MDT 2022 (while helping Matthieu Herrb to solve some X and fvwm2 related issue) this problem wasn't there. For now, it's all I know. > > > > > https://marc.info/?l=openbsd-bugs=166286641515911=2 > > > > I'm not sure if it's the same bug. In my case Xorg crashes (trace > > below). > > I don't think that is related. Quite different hardware and a different > Mesa driver. > > > > > It happens with modesetting driver only, NOT with intel. > > > > It happens using fvwm2 while browsing its menus. Text desapears, the > > screen flashes a few times and eventually X crashes. > > > > I've build a new kernel activating *all* the options in this patch > > but that did NOT solve the issue. > > > > https://marc.info/?l=openbsd-bugs=166286799416220=2 > > That is also unrelated. > > > > > > > # egdb -ex bt -batch /usr/xobj/xserver/hw/xfree86/Xorg Xorg.core > > [New process 532797] > > [New process 424021] > > [New process 348856] > > Core was generated by `Xorg'. > > Program terminated with signal SIGABRT, Aborted. > > #0 thrkill () at /tmp/-:3 > > [Current thread is 1 (process 532797)] > > #0 thrkill () at /tmp/-:3 > > #1 0x0abab5e5b0fe in _libc_abort () at > > /usr/src/lib/libc/stdlib/abort.c:51 > > #2 0x0ab89683e00a in OsAbort () > > #3 0x0ab896844e4e in AbortServer () > > #4 0x0ab8968434eb in FatalError () > > #5 0x0ab89683b684 in OsSigHandler () > > #6 > > #7 thrkill () at /tmp/-:3 > > #8 0x0abab5e5b0fe in _libc_abort () at > > /usr/src/lib/libc/stdlib/abort.c:51 > > #9 0x0abac74d84e8 in ?? () from > > /usr/X11R6/lib/modules/dri/crocus_dri.so > > #10 0x0abac74d5d30 in ?? () from > > /usr/X11R6/lib/modules/dri/crocus_dri.so > > #11 0x0abac6c10197 in ?? () from > > /usr/X11R6/lib/modules/dri/crocus_dri.so > > #12 0x0abb67a0d709 in _glamor_block_handler () from > > /usr/X11R6/lib/modules/libglamoregl.so > > #13 0x0abb7863c24a in msBlockHandler () from > > /usr/X11R6/lib/modules/drivers/modesetting_drv.so > > #14 0x0ab896694414 in BlockHandler () > > #15 0x0ab896833b28 in WaitForSomething () > > #16 0x0ab89668843c in Dispatch () > > #17 0x0ab89669375c in dix_main () > > #18 0x0ab89667a2d2 in _start () > > > > # dmesg | tail > > i915_vma_coredump_create: stub > > i915_vma_coredump_create: stub > > i915_vma_coredump_create: stub > > i915_vma_coredump_create: stub > > i915_vma_coredump_create: stub > > pool_fini: stub > > err_free_sgl: stub > > drm:pid77674:intel_gt_reset *NOTICE* [drm] Resetting chip for stopped > > heartbeat on rcs0 > > inteldrm0: no ifp > > drm:pid77674:mark_guilty *NOTICE* [drm] Xorg[27880] context reset due to > > GPU hang > > I'll see if I can reproduce this on another 965 machine. > > > > > > > dmesg (generated by sendbug) > > > > OpenBSD 7.2 (GENERIC.MP) #2: Fri Sep 16 12:36:28 CEST 2022 > > morl...@chancha.roquesor.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > real mem = 4135260160 (3943MB) > > avail mem = 3992539136 (3807MB) > > random: good seed from bootblocks > > mpath0 at root > > scsibus0 at mpath0: 256 targets > > mainbus0 at root > > bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xeb920 (70 entries) > > bios0: vendor Hewlett-Packard version "786E1 v01.16" date 08/17/2011 > > bios0: Hewlett-Packard HP Compaq dc7700 Convertible Minitower > > acpi0 at bios0: ACPI 1.0 > > acpi0: sleep states S0 S3 S4 S5 > > acpi0: tables DSDT FACP APIC ASF! MCFG TCPA SLIC HPET > > acpi0: wakeup devices PCI0(S4) COM1(S4) PEG1(S4) IGBE(S4) PCX1(S4) PCX2(S4) > > HUB_(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) EUS1(S3) EUS2(S3) > > PBTN(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)2 CPU 4300 @ 1.80GHz, 1795.59 MHz, 06-0f-02 > > 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,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN > > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 2MB > > 64b/line 8-way L2 cache > > cpu0: smt 0, core 0, package 0 > > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > > cpu0: apic clock running at 199MHz > > cpu0: mwait min=64, max=64, C-substates=0.2, IBE > > cpu1 at mainbus0:
Re: drm makes X crash (only with modesetting)
On Fri, Sep 16, 2022 at 01:55:13PM +0200, Walter Alejandro Iglesias wrote: > Hello everone, > > After upgrading to the latest snapshot I'm experiencing something > similar to what's described here: What snapshot were you running before? > > https://marc.info/?l=openbsd-bugs=166286641515911=2 > > I'm not sure if it's the same bug. In my case Xorg crashes (trace > below). I don't think that is related. Quite different hardware and a different Mesa driver. > > It happens with modesetting driver only, NOT with intel. > > It happens using fvwm2 while browsing its menus. Text desapears, the > screen flashes a few times and eventually X crashes. > > I've build a new kernel activating *all* the options in this patch > but that did NOT solve the issue. > > https://marc.info/?l=openbsd-bugs=166286799416220=2 That is also unrelated. > > > # egdb -ex bt -batch /usr/xobj/xserver/hw/xfree86/Xorg Xorg.core > [New process 532797] > [New process 424021] > [New process 348856] > Core was generated by `Xorg'. > Program terminated with signal SIGABRT, Aborted. > #0 thrkill () at /tmp/-:3 > [Current thread is 1 (process 532797)] > #0 thrkill () at /tmp/-:3 > #1 0x0abab5e5b0fe in _libc_abort () at > /usr/src/lib/libc/stdlib/abort.c:51 > #2 0x0ab89683e00a in OsAbort () > #3 0x0ab896844e4e in AbortServer () > #4 0x0ab8968434eb in FatalError () > #5 0x0ab89683b684 in OsSigHandler () > #6 > #7 thrkill () at /tmp/-:3 > #8 0x0abab5e5b0fe in _libc_abort () at > /usr/src/lib/libc/stdlib/abort.c:51 > #9 0x0abac74d84e8 in ?? () from /usr/X11R6/lib/modules/dri/crocus_dri.so > #10 0x0abac74d5d30 in ?? () from /usr/X11R6/lib/modules/dri/crocus_dri.so > #11 0x0abac6c10197 in ?? () from /usr/X11R6/lib/modules/dri/crocus_dri.so > #12 0x0abb67a0d709 in _glamor_block_handler () from > /usr/X11R6/lib/modules/libglamoregl.so > #13 0x0abb7863c24a in msBlockHandler () from > /usr/X11R6/lib/modules/drivers/modesetting_drv.so > #14 0x0ab896694414 in BlockHandler () > #15 0x0ab896833b28 in WaitForSomething () > #16 0x0ab89668843c in Dispatch () > #17 0x0ab89669375c in dix_main () > #18 0x0ab89667a2d2 in _start () > > # dmesg | tail > i915_vma_coredump_create: stub > i915_vma_coredump_create: stub > i915_vma_coredump_create: stub > i915_vma_coredump_create: stub > i915_vma_coredump_create: stub > pool_fini: stub > err_free_sgl: stub > drm:pid77674:intel_gt_reset *NOTICE* [drm] Resetting chip for stopped > heartbeat on rcs0 > inteldrm0: no ifp > drm:pid77674:mark_guilty *NOTICE* [drm] Xorg[27880] context reset due to GPU > hang I'll see if I can reproduce this on another 965 machine. > > > dmesg (generated by sendbug) > > OpenBSD 7.2 (GENERIC.MP) #2: Fri Sep 16 12:36:28 CEST 2022 > morl...@chancha.roquesor.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 4135260160 (3943MB) > avail mem = 3992539136 (3807MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xeb920 (70 entries) > bios0: vendor Hewlett-Packard version "786E1 v01.16" date 08/17/2011 > bios0: Hewlett-Packard HP Compaq dc7700 Convertible Minitower > acpi0 at bios0: ACPI 1.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP APIC ASF! MCFG TCPA SLIC HPET > acpi0: wakeup devices PCI0(S4) COM1(S4) PEG1(S4) IGBE(S4) PCX1(S4) PCX2(S4) > HUB_(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) EUS1(S3) EUS2(S3) > PBTN(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)2 CPU 4300 @ 1.80GHz, 1795.59 MHz, 06-0f-02 > 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,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 2MB 64b/line > 8-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 199MHz > cpu0: mwait min=64, max=64, C-substates=0.2, IBE > cpu1 at mainbus0: apid 1 (application processor) > cpu1: Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz, 1795.51 MHz, 06-0f-02 > 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,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN > cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 2MB 64b/line > 8-way L2 cache > cpu1: smt 0, core 1, package 0 > ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped > acpimcfg0 at acpi0 > acpimcfg0: addr 0xf400, bus 0-63 > acpihpet0 at acpi0: 14318179 Hz > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus -1 (PEG1) > acpiprt2 at acpi0: bus 32
Re: EvolveIII laptop X quit working
On 9/15/22 18:58, Chris Narkiewicz wrote: On Mon, Jul 25, 2022 at 03:27:30PM -0400, Nick Holland wrote: Somewhere between 7.1 release and -current, X quit working on this machine. It is a really lousy machine, wireless doesn't work, slow, etc., and it cost $80 new (and is currently $60), so "What do you expect?" is a valid response. Hey, latest snapshot seems to be working on my machine (StarLite MkIV) that experienced the same issue. Could you confirm that this has been fixed on your hardware as well? Confirmed, late last night's snap worked for me as well. Did both an upgrade and a clean install to verify no old "fixes" were laying around. On this machine, the trackpad is not functional in X, but that was true of the 7.1-release as well, I think. Different "problem". Nick.
drm makes X crash (only with modesetting)
Hello everone, After upgrading to the latest snapshot I'm experiencing something similar to what's described here: https://marc.info/?l=openbsd-bugs=166286641515911=2 I'm not sure if it's the same bug. In my case Xorg crashes (trace below). It happens with modesetting driver only, NOT with intel. It happens using fvwm2 while browsing its menus. Text desapears, the screen flashes a few times and eventually X crashes. I've build a new kernel activating *all* the options in this patch but that did NOT solve the issue. https://marc.info/?l=openbsd-bugs=166286799416220=2 # egdb -ex bt -batch /usr/xobj/xserver/hw/xfree86/Xorg Xorg.core [New process 532797] [New process 424021] [New process 348856] Core was generated by `Xorg'. Program terminated with signal SIGABRT, Aborted. #0 thrkill () at /tmp/-:3 [Current thread is 1 (process 532797)] #0 thrkill () at /tmp/-:3 #1 0x0abab5e5b0fe in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51 #2 0x0ab89683e00a in OsAbort () #3 0x0ab896844e4e in AbortServer () #4 0x0ab8968434eb in FatalError () #5 0x0ab89683b684 in OsSigHandler () #6 #7 thrkill () at /tmp/-:3 #8 0x0abab5e5b0fe in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51 #9 0x0abac74d84e8 in ?? () from /usr/X11R6/lib/modules/dri/crocus_dri.so #10 0x0abac74d5d30 in ?? () from /usr/X11R6/lib/modules/dri/crocus_dri.so #11 0x0abac6c10197 in ?? () from /usr/X11R6/lib/modules/dri/crocus_dri.so #12 0x0abb67a0d709 in _glamor_block_handler () from /usr/X11R6/lib/modules/libglamoregl.so #13 0x0abb7863c24a in msBlockHandler () from /usr/X11R6/lib/modules/drivers/modesetting_drv.so #14 0x0ab896694414 in BlockHandler () #15 0x0ab896833b28 in WaitForSomething () #16 0x0ab89668843c in Dispatch () #17 0x0ab89669375c in dix_main () #18 0x0ab89667a2d2 in _start () # dmesg | tail i915_vma_coredump_create: stub i915_vma_coredump_create: stub i915_vma_coredump_create: stub i915_vma_coredump_create: stub i915_vma_coredump_create: stub pool_fini: stub err_free_sgl: stub drm:pid77674:intel_gt_reset *NOTICE* [drm] Resetting chip for stopped heartbeat on rcs0 inteldrm0: no ifp drm:pid77674:mark_guilty *NOTICE* [drm] Xorg[27880] context reset due to GPU hang dmesg (generated by sendbug) OpenBSD 7.2 (GENERIC.MP) #2: Fri Sep 16 12:36:28 CEST 2022 morl...@chancha.roquesor.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4135260160 (3943MB) avail mem = 3992539136 (3807MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xeb920 (70 entries) bios0: vendor Hewlett-Packard version "786E1 v01.16" date 08/17/2011 bios0: Hewlett-Packard HP Compaq dc7700 Convertible Minitower acpi0 at bios0: ACPI 1.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC ASF! MCFG TCPA SLIC HPET acpi0: wakeup devices PCI0(S4) COM1(S4) PEG1(S4) IGBE(S4) PCX1(S4) PCX2(S4) HUB_(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) EUS1(S3) EUS2(S3) PBTN(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)2 CPU 4300 @ 1.80GHz, 1795.59 MHz, 06-0f-02 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,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 2MB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 199MHz cpu0: mwait min=64, max=64, C-substates=0.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz, 1795.51 MHz, 06-0f-02 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,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 2MB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped acpimcfg0 at acpi0 acpimcfg0: addr 0xf400, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG1) acpiprt2 at acpi0: bus 32 (PCX1) acpiprt3 at acpi0: bus -1 (PCX2) acpiprt4 at acpi0: bus 7 (HUB_) acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 com0 at acpi0 COM1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo "PNP0003" at acpi0 not configured tpm0 at acpi0 TPM_ 1.2 (TIS) addr 0x4e/0x2, device 0x rev 0xff acpibtn0 at acpi0: PBTN "PNP0C14" at acpi0 not configured acpicpu0 at acpi0: C1(@1 halt!), PSS acpicpu1 at acpi0: C1(@1 halt!), PSS cpu0: Enhanced SpeedStep 1795 MHz: speeds: 1800, 1200 MHz pci0 at mainbus0
Re: re(4) drivers not working
On Fri, Sep 16, 2022 at 09:39:56AM +0200, Stefan Sperling wrote: > On Fri, Sep 16, 2022 at 08:27:59AM +0200, Adam Szewczyk wrote: > > Checked on actual hardware it seems to work fine. So I report it also to > > Qubes and Xen Project, but marmarek (head of qubes development team) > > suggest that it can be a problem with driver itself: > > "I'm not sure if that's relevant, but a common cause is incorrect MSI / > > MSI-X detection/support by the driver. HVM in Qubes do not support MSI-X, > > but do support MSI. MSI-X, even if the device really supports it, is masked > > from PCI capabilities. Driver should fallback to MSI (or INTx) if MSI-X > > fails to setup (or isn't there at all), but many drivers have this path > > buggy, since it isn't exercised in most common (native) scenario." > > re(4) only uses MSI, it does not ever even try MSI-X. As can be seen here: > https://github.com/openbsd/src/blob/master/sys/dev/pci/if_re_pci.c#L161 But there has been at least one report of MSI, (not MSI-X), causing the error that the OP is seeing with an 're' device on bare hardware, (no hypervisor): https://marc.info/?l=openbsd-tech=165987603706259=2 So maybe test the patch in that mail to see if using a regular non-MSI interrupt mitigates the problem. Then look for the real bug if it does.
Re: re(4) drivers not working
On Fri, Sep 16, 2022 at 09:58:44AM +0200, Adam Szewczyk wrote: > My mistake in creating a bug for wireless it should be iwm (copied wrong > file name in a hurry). Is that are you wrote about iwx also true for iwm? At this low level the drivers are equivalent. > Sorry for the trouble. I just want to figured it out which project have, a > bug and create there a ticket. It was my first contact with BSD also so I > don't know nothing about the internals. It can be difficult when people send you around between each other's projects, I understand that. And one can never know for sure, there are so many layers involved that it is impossible to tell what's wrong without knowing details. PCI-passthrough is complicated. The best way to make progress is trying to eliminate possibile root causes for the issue. Have you tried PCI passthrough with KVM yet, just to see if a different hypervisor works fine? And have you tried on a different hardware configuration (different CPU/BIOS)? Are you sure you applied all the necessary BIOS tweaks for PCI passthrough to actually work? In any case, without solid evidence that something is wrong in the OpenBSD drivers, I don't expect anyone here will have motivation to hunt for a bug. Our developers don't always have time to help chase problems down from the very top (error message) to the very bottom (root cause). We need more information and clear evidence that other possible root causes have already been eliminated. Based on past experience with such bug reports, when it works just fine on bare metal then there is usually a hypervisor or BIOS problem.
Re: re(4) drivers not working
My mistake in creating a bug for wireless it should be iwm (copied wrong file name in a hurry). Is that are you wrote about iwx also true for iwm? Sorry for the trouble. I just want to figured it out which project have, a bug and create there a ticket. It was my first contact with BSD also so I don't know nothing about its internals. pt., 16 wrz 2022, 09:39 użytkownik Stefan Sperling napisał: > On Fri, Sep 16, 2022 at 08:27:59AM +0200, Adam Szewczyk wrote: > > Checked on actual hardware it seems to work fine. So I report it also to > > Qubes and Xen Project, but marmarek (head of qubes development team) > > suggest that it can be a problem with driver itself: > > "I'm not sure if that's relevant, but a common cause is incorrect MSI / > > MSI-X detection/support by the driver. HVM in Qubes do not support MSI-X, > > but do support MSI. MSI-X, even if the device really supports it, is > masked > > from PCI capabilities. Driver should fallback to MSI (or INTx) if MSI-X > > fails to setup (or isn't there at all), but many drivers have this path > > buggy, since it isn't exercised in most common (native) scenario." > > re(4) only uses MSI, it does not ever even try MSI-X. As can be seen here: > https://github.com/openbsd/src/blob/master/sys/dev/pci/if_re_pci.c#L161 > > iwx(4) first tries MSI-X, then falls back on MSI: > https://github.com/openbsd/src/blob/master/sys/dev/pci/if_iwx.c#L10573 > Your iwx firmare load failure looks like a DMA problem to me. > > I don't see any actionable information in your bug reports as far > as fixing our drivers goes. Sorry. >
Re: re(4) drivers not working
On Fri, Sep 16, 2022 at 08:27:59AM +0200, Adam Szewczyk wrote: > Checked on actual hardware it seems to work fine. So I report it also to > Qubes and Xen Project, but marmarek (head of qubes development team) > suggest that it can be a problem with driver itself: > "I'm not sure if that's relevant, but a common cause is incorrect MSI / > MSI-X detection/support by the driver. HVM in Qubes do not support MSI-X, > but do support MSI. MSI-X, even if the device really supports it, is masked > from PCI capabilities. Driver should fallback to MSI (or INTx) if MSI-X > fails to setup (or isn't there at all), but many drivers have this path > buggy, since it isn't exercised in most common (native) scenario." re(4) only uses MSI, it does not ever even try MSI-X. As can be seen here: https://github.com/openbsd/src/blob/master/sys/dev/pci/if_re_pci.c#L161 iwx(4) first tries MSI-X, then falls back on MSI: https://github.com/openbsd/src/blob/master/sys/dev/pci/if_iwx.c#L10573 Your iwx firmare load failure looks like a DMA problem to me. I don't see any actionable information in your bug reports as far as fixing our drivers goes. Sorry.
iwx-firmware-20211101.tgz drivers not working with Intel Wireless AC-9560 NIC
Sorry I report wrong version of the driver. It should be iwm-firmware-20220111.tgz of course.
Re: re(4) drivers not working
Checked on actual hardware it seems to work fine. So I report it also to Qubes and Xen Project, but marmarek (head of qubes development team) suggest that it can be a problem with driver itself: "I'm not sure if that's relevant, but a common cause is incorrect MSI / MSI-X detection/support by the driver. HVM in Qubes do not support MSI-X, but do support MSI. MSI-X, even if the device really supports it, is masked from PCI capabilities. Driver should fallback to MSI (or INTx) if MSI-X fails to setup (or isn't there at all), but many drivers have this path buggy, since it isn't exercised in most common (native) scenario." czw., 15 wrz 2022 o 08:03 Adam Szewczyk napisał(a): > Ok, I will check if I have some time to perform installation on actual HW, > but the idea is to be able to run it on xen. There is growing interest in > using OpenBSD, as a sys-net for Qubes OS instead of the original one based > on Linux. So it is crucial for me to be able to use re(4) and iwm(4) with > my NICs on Xen. I understand that if the issue will be caused by having xen > in the middle I should report the issue to its maintainers. > > czw., 15 wrz 2022 o 02:03 Jonathan Gray napisał(a): > >> On Wed, Sep 14, 2022 at 10:23:32PM +0200, Adam Szewczyk wrote: >> > After installation of OpenBSD as HVM on Qubes OS with passed through >> > Realtek NIC driver starts to spamming with "re0: watchdog timeout" >> message >> > and not working. Attaching dmesg. >> >> Try without xen. It may be messing up interrupts. >> >> > >> > OpenBSD 7.1 (GENERIC.MP) #465: Mon Apr 11 18:03:57 MDT 2022 >> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/ >> GENERIC.MP >> > real mem = 1040183296 (991MB) >> > avail mem = 991436800 (945MB) >> > random: good seed from bootblocks >> > mpath0 at root >> > scsibus0 at mpath0: 256 targets >> > mainbus0 at root >> > bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xfc10 (12 entries) >> > bios0: vendor Xen version "4.14.5" date 08/24/2022 >> > bios0: Xen HVM domU >> > acpi0 at bios0: ACPI 4.0 >> > acpi0: sleep states S3 S4 S5 >> > acpi0: tables DSDT FACP APIC HPET WAET SSDT SSDT >> > acpi0: wakeup devices >> > acpitimer0 at acpi0: 3579545 Hz, 32 bits >> > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat >> > ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 48 pins, remapped >> > cpu0 at mainbus0: apid 0 (boot processor) >> > cpu0: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz, 2593.27 MHz, 06-9e-0a >> > cpu0: >> > >> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN >> > cpu0: 256KB 64b/line 8-way L2 cache >> > cpu0: smt 0, core 0, package 0 >> > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges >> > cpu0: apic clock running at 100MHz >> > cpu1 at mainbus0: apid 2 (application processor) >> > cpu1: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz, 2592.03 MHz, 06-9e-0a >> > cpu1: >> > >> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN >> > cpu1: 256KB 64b/line 8-way L2 cache >> > cpu1: smt 0, core 1, package 0 >> > acpihpet0 at acpi0: 6250 Hz >> > acpiprt0 at acpi0: bus 0 (PCI0) >> > acpipci0 at acpi0 PCI0 >> > acpicmos0 at acpi0 >> > "ACPI0007" at acpi0 not configured >> > "ACPI0007" at acpi0 not configured >> > acpicpu0 at acpi0: C1(@1 halt!) >> > acpicpu1 at acpi0: C1(@1 halt!) >> > cpu0: using VERW MDS workaround (except on vmm entry) >> > pvbus0 at mainbus0: Xen 4.14 >> > xen0 at pvbus0: features 0x2705, 2048 grant table frames, event channel >> 1 >> > xbf0 at xen0 backend 0 channel 6: disk >> > scsibus1 at xbf0: 1 targets >> > sd0 at scsibus1 targ 0 lun 0: >> > sd0: 10240MB, 512 bytes/sector, 20971520 sectors >> > xbf1 at xen0 backend 0 channel 7: disk >> > scsibus2 at xbf1: 1 targets >> > sd1 at scsibus2 targ 0 lun 0: >> > sd1: 2048MB, 512 bytes/sector, 4194304 sectors >> > xbf2 at xen0 backend 0 channel 8: disk >> > scsibus3 at xbf2: 1 targets >> > sd2 at scsibus3 targ 0 lun 0: >> > sd2: 10240MB, 512 bytes/sector, 20971520 sectors >> > xnf0 at xen0 backend 113 channel 9: address 00:16:3e:5e:6c:00 >> > pci0 at mainbus0 bus 0 >> > pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02 >> > pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00 >> > pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, >> channel >> > 0 wired to compatibility, channel 1
