Re: AMDGPU in current issue
On Fri, Aug 02, 2019 at 03:11:54AM -0500, Charlie Burnett wrote:
> Hey-
> I'd been messing around with the AMDGPU on current (which I'm aware is very
> experimental) and had very few issues with it using a Vega 56 GPU. I
> recently swapped to another Vega GPU (Radeon VII) and have issues with the
> display not showing anything. Still boots fine, in that I can still enter
> commands (i.e. reboot) so it has to be a display issue. I tried searching
> for the diff where the firmware was added which I'm certain I saw (for Vega
> 20) but can't seem to find it in the commit history. Anyone have a fix for
> it, and if not, who should I talk to if I wanted to help get it working? I
> saw most of the AMDGPU commits have been by @jonathangray if he would be
> the best option.
> Thanks!
vega20 firmware was added when ports/sysutils/firmware/amdgpu was
updated to 20190312.
vega20 is marked as experimental in the version of drm we have, but we
don't currently check the flag on probe like linux does.
The following diff will prevent amdgpu from matching on devices
in the amdgpu_pciidlist table with the AMD_EXP_HW_SUPPORT flag
(currently these are all vega20 ids).
Index: sys/dev/pci/drm/include/drm/drm_drv.h
===
RCS file: /cvs/src/sys/dev/pci/drm/include/drm/drm_drv.h,v
retrieving revision 1.2
diff -u -p -r1.2 drm_drv.h
--- sys/dev/pci/drm/include/drm/drm_drv.h 25 Jul 2019 05:48:16 -
1.2
+++ sys/dev/pci/drm/include/drm/drm_drv.h 2 Aug 2019 03:29:58 -
@@ -291,5 +291,7 @@ static inline bool drm_drv_uses_atomic_m
intdrm_dev_register(struct drm_device *, unsigned long);
void drm_dev_unregister(struct drm_device *);
intdrm_getpciinfo(struct drm_device *, void *, struct drm_file *);
+const struct drm_pcidev*drm_find_description(int, int,
+const struct drm_pcidev *);
#endif
Index: sys/dev/pci/drm/amd/amdgpu/amdgpu_kms.c
===
RCS file: /cvs/src/sys/dev/pci/drm/amd/amdgpu/amdgpu_kms.c,v
retrieving revision 1.3
diff -u -p -r1.3 amdgpu_kms.c
--- sys/dev/pci/drm/amd/amdgpu/amdgpu_kms.c 4 Jul 2019 03:39:07 -
1.3
+++ sys/dev/pci/drm/amd/amdgpu/amdgpu_kms.c 2 Aug 2019 03:35:35 -
@@ -1337,10 +1337,23 @@ int amdgpu_debugfs_firmware_init(struct
int
amdgpu_probe(struct device *parent, void *match, void *aux)
{
+ struct pci_attach_args *pa = aux;
+ const struct drm_pcidev *id_entry;
+ unsigned long flags = 0;
+
if (amdgpu_fatal_error)
return 0;
- if (drm_pciprobe(aux, amdgpu_pciidlist))
- return 20;
+
+ id_entry = drm_find_description(PCI_VENDOR(pa->pa_id),
+ PCI_PRODUCT(pa->pa_id), amdgpu_pciidlist);
+ if (id_entry != NULL) {
+ flags = id_entry->driver_data;
+ if (flags & AMD_EXP_HW_SUPPORT)
+ return 0;
+ else
+ return 20;
+ }
+
return 0;
}
AMDGPU in current issue
Hey- I'd been messing around with the AMDGPU on current (which I'm aware is very experimental) and had very few issues with it using a Vega 56 GPU. I recently swapped to another Vega GPU (Radeon VII) and have issues with the display not showing anything. Still boots fine, in that I can still enter commands (i.e. reboot) so it has to be a display issue. I tried searching for the diff where the firmware was added which I'm certain I saw (for Vega 20) but can't seem to find it in the commit history. Anyone have a fix for it, and if not, who should I talk to if I wanted to help get it working? I saw most of the AMDGPU commits have been by @jonathangray if he would be the best option. Thanks!
Re: su - root => segmentation fault
Amd64 from 30 jul. What does the "your kernel does not match the userspace" mean? ср, 31 июл. 2019 г., 19:22 Gregory Edigarov : > On 31.07.19 17:00, Solene Rapenne wrote: > > On Wed, Jul 31, 2019 at 04:49:54PM +0500, dmitry.sensei wrote: > >> Hi! > >> why did it happen? > >> > >> OpenBSD 6.5 current > >> $su - root > >> root's password: > >> Segmentation fault > >> $ doas su - root > >> # > >> > >> -- > >> Dmitry Orlov > > what current? What arch? > > > > works for me© > > OpenBSD 6.5-current (GENERIC.MP) #153: Sun Jul 28 20:33:09 MDT 2019 > usually it means that your kernel does not match the userspace > >
Re: storage
On 2019-08-01, Gustavo Rios wrote: > Doaes anybody uses Dell machines with OpenBSD ? Loads of people. Usually they are quite low hassle. > Is the current models fully supported by OpenBSD (In special raid and > network interfaces ) There are lots of current models and lots of options. Some definitely work, for others (especially less common options) it's hard to say, so if you have specific hardware in mind then ask about that.
Re: problem to copy a (possibly large) file over a network device
Nick Holland writes: > On 7/31/19 3:45 AM, Rudolf Sykora wrote: > [probably irrelevant stuff snipped] I believe you snipped quite a relevant part. > Well, that looks broke. Not supposed to do that. yes. > Well, looking at the version of OpenBSD that you are using ... oh. 6.5 GENERIC.MP#2 amd64 stable, with all syspatches applied. > Well, your dmesg shows ... hmm. I am attaching it to this email. > Looking at your rsync command line I see ... well... Here you have it, though most probably irrelevant: /usr/local/bin/rsync -a --delete --exclude-from=/etc/rsync-backup_exclude -e ssh /home /var/www bac...@utef15.troja.mff.cuni.cz:odin (The problem stays with scp, or anything, once a network device (localhost is enough) participates.) > Your environment is ... hm. no idea about that either. Do not know what you mean. > As for your follow up, no, there is no setting deliberately set to, > "don't work properly" you need to change to "work correctly" in > OpenBSD. Nobody spoke about "deliberately", or working in a "binary" way. In the follow-up I added the information that the size of files can be larger than 10 GB. In some systems (e.g. plan9) there are quite a few limits/constants which lead, or can lead, to problems when exceeded. That is what was meant by the settings. Thanks anyway Ruda dmesg output: OpenBSD 6.5 (GENERIC.MP) #2: Tue Jul 23 23:38:56 CEST 2019 r...@syspatch-65-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17040211968 (16250MB) avail mem = 16514150400 (15749MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeceb0 (84 entries) bios0: vendor Dell Inc. version "A21" date 09/21/2015 bios0: Dell Inc. OptiPlex 9010 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT TCPA MCFG HPET SSDT SSDT SSDT DMAR ASF! SSDT SLIC acpi0: wakeup devices UAR1(S3) P0P1(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) USB6(S3) USB7(S3) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(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) i7-3770 CPU @ 3.40GHz, 3392.92 MHz, 06-3a-09 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3392.30 MHz, 06-3a-09 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3392.30 MHz, 06-3a-09 cpu2: 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3392.30 MHz, 06-3a-09 cpu3: 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3392.30 MHz, 06-3a-09 cpu4:
Re: problem to copy a (possibly large) file over a network device
On 7/31/19 3:45 AM, Rudolf Sykora wrote: > Dear list, [probably irrelevant stuff snipped] > I actually wanted to do a backup of the subtree with rsync over the > network, but that didn't work, spitting sth. like > > rsync error: unexplained error (code 255) at io.c(820) [sender=3.1.3] > [sender] _exit_cleanup(code=10, file=io.c, line=820): about to call > exit(255) ... Well, that looks broke. Not supposed to do that. > As I have no idea what can cause this behaviour, I am asking for any > help. Well, looking at the version of OpenBSD that you are using ... oh. Well, your dmesg shows ... hmm. Looking at your rsync command line I see ... well... Your environment is ... hm. no idea about that either. Not much to work with you on here other than you got an error message you probably shouldn't have got. As for your follow up, no, there is no setting deliberately set to, "don't work properly" you need to change to "work correctly" in OpenBSD. Nick.
Re: sysupgrade (Was: Re: Kernel crash in OpenBSD 6.5)
Thank you for the clarification!
storage
Doaes anybody uses Dell machines with OpenBSD ? Is the current models fully supported by OpenBSD (In special raid and network interfaces ) Thanks in advance. -- Pag Bem Fácil Ltda www.pagbemfacil.com.br
Re: sysupgrade (Was: Re: Kernel crash in OpenBSD 6.5)
Harald Dunkel wrote: > On 8/1/19 2:33 PM, Maurice McCarthy wrote: > > In the past it was not uncommon for non-X programs in base to have > > dependencies in Xenocara. Are you certain that this is no longer so? > > > > Yup Never been the case. No base program uses a include or library from X. There is 1 feature that has a runtime dependency, and there used to be a 2nd one which was deleted. X needs base, but base does not need X. The real issue is we rarely create non-X variations of ports. Users can install a package intending to only used the non-X aspects of such software, but if it links against X ... if they avoided install the X sets in particularily xbase, then they are SOL. So, I'll say it again: people saving disk space in this way are largely being foolish, or selecting the practice of "non-default install, so you own all the pieces". When people make non-default changes to their systems they should think long and hard before submitting any bug reports of any kind, since the problem could be caused by their own decisions...
Re: sysupgrade (Was: Re: Kernel crash in OpenBSD 6.5)
On 8/1/19 2:33 PM, Maurice McCarthy wrote: In the past it was not uncommon for non-X programs in base to have dependencies in Xenocara. Are you certain that this is no longer so? Yup
Re: sysupgrade (Was: Re: Kernel crash in OpenBSD 6.5)
On 2019-08-01, Harald Dunkel wrote: > Hi folks, > > On 7/30/19 3:08 PM, Hrvoje Popovski wrote: >> >> try to update both boxes to latest snapshot at least because in snapshot >> you have excellent tool called sysupgrade ... you will love it :) >> >> with this tool you can upgrade os to latest snapshot without any problem >> over ssh :) >> > This is cool. > > Due to space and speed restrictions (compact flash card) and to reduce > downtime I would like to avoid the games and the Xwindow "balast" on my > gateways. Does sysupgrade recognize the tar balls that are already > installed, or does it become a "sysinstall" in this case? > > Sorry for asking, but the man page https://man.openbsd.org/sysupgrade > doesn't tell. A normal sysupgrade run installs all sets. You can manually do part of what you want with sysupgrade -n, this still downloads all sets but you're able to rm the unwanted ones before rebooting onto the bsd.upgrade kernel and at least save untarring them.
Dell PE R740, Intel X710 QuadPort & LACP not working
Hi Misc, we bought two new Dell PowerEdges R740. Each System has 3 intel X770 based quadport sfp+ nics. Onboard are two further intel i350 based sfp+ ports. The firewalls are running OpenBSD 6.5 stable. To test lacp 802.3ad with ix and ixl based interfaces I build two trunks which directly connect the two systems: +-+ trunk1 +-+ | ix0||ix0 | | ix1||ix1 | | openbsd1 || openbsd2 | | ixl1||ixl1 | | ixl6||ixl6 | +-+ trunk2 +-+ fw1: /etc/hostname.trunk1 up trunkport ix0 trunkport ix1 trunkproto lacp lacpmode active lacptimeout fast inet 10.0.0.1/30 /etc/hostname.trunk2 up trunkport ixl6 trunkport ixl1 trunkproto lacp lacpmode active lacptimeout fast inet 10.1.0.1/3 fw2: /etc/hostname.trunk1 up trunkport ix0 trunkport ix1 trunkproto lacp lacpmode active lacptimeout fast inet 10.0.0.2/30 /etc/hostname.trunk2 up trunkport ixl6 trunkport ixl1 trunkproto lacp lacpmode active lacptimeout fast inet 10.1.0.2/3 Trunk1 with ix based ports behaved as expected. Disconnecting one of the fibers to simulate a broken one or doing ifconfig ix0|ix1 down has not disturbed the ping between the two firewalls. Futhermore doing an ifconfig ix0|ix1 up brought that interface back to the trunk correctly. The first impression with testing ixl based ports looked good. Doing ifconfig ixl1|ixl6 down let trunk switching to the only one active interface. But then checking the deactivated interface with ifconfig ixl6 transceiver showed the following: # ifconfig xl6 transceiver ixl6: flags=8902 mtu 1500 lladdr f8:f2:1e:65:30:e0 index 11 priority 0 llprio 3 trunk: trunkdev trunk2 media: Ethernet autoselect (10GbaseSR full-duplex) status: active transceiver: SFP LC, 850 nm, 80m OM2, 30m OM1, 300m OM3 model: Intel Corp P.8596.02 rev A serial: F78Y3VQ, date: 2019-06-12 voltage: 3.33 V, bias current: 5.64 mA temp: 29.80 C (low -10.00 C, high 90.00 C) tx: -3.88 dBm (low -9.30 dBm, high 1.00 dBm) rx: -3.40 dBm (low -13.10 dBm, high 1.00 dBm) Hmm, okey the status is still active. But tcpdump didnt recognized any packets on that device. Then i tried to reactivate ixl6 with ifconfig ixl6 up: # ifconfig ixl6 transceiver ixl6: flags=8943 mtu 1500 lladdr f8:f2:1e:65:30:e0 index 11 priority 0 llprio 3 trunk: trunkdev trunk2 media: Ethernet autoselect (10GbaseSR full-duplex) status: active transceiver: SFP LC, 850 nm, 80m OM2, 30m OM1, 300m OM3 model: Intel Corp P.8596.02 rev A serial: F78Y3VQ, date: 2019-06-12 voltage: 3.33 V, bias current: 5.56 mA temp: 28.34 C (low -10.00 C, high 90.00 C) tx: -3.95 dBm (low -9.30 dBm, high 1.00 dBm) rx: -3.39 dBm (low -13.10 dBm, high 1.00 dBm) The UP flag is set but trunk2 had some problems. The lacp_state actor, partner and status was switching beween different states: trunkport ixl6 lacp_state actor activity,timeout,aggregation,defaulted trunkport ixl6 lacp_state partner aggregation,sync,collecting, distributing trunkport ixl6 ... trunkport ixl6 lacp_state actor activity,timeout,aggregation,expired trunkport ixl6 lacp_state partner activity,timeout,aggregation, collecting,distributing,defaulted trunkport ixl6 active ... trunkport ixl6 lacp_state actor activity,timeout,aggregation,sync, collecting,distributing,defaulted trunkport ixl6 lacp_state partner aggregation,sync,collecting, distributing trunkport ixl6 collecting,distributing ... trunkport ixl6 lacp_state actor activity,timeout,aggregation,sync, collecting,distributing,defaulted trunkport ixl6 lacp_state partner aggregation,sync,collecting, distributing trunkport ixl6 collecting,distributing I was not able get the trunk fully functional. Only a reboot could solved this issue. Furthermore simulating a broken fiber by pulling it out showed a different behavior. By plugging out the fiber of ixl6 the interface status changed correctly to status: no carrier. By plugging it back the interface status change back to status: active. And the trunk uses both trunkports correctly, good! I also tested this setup with two switches, which are configured as a mlag (multi chassis link aggregation) running Cumulus Linux. We want to use mlag to do lacp without the need for stacking. +-+ +-- + | openbsd ixl6|-| cumulus linux | | 1 ixl1|\ /| switch 1| +-+ \ / +---++--+ / || mlag +-+ / \ +---++--+ | openbsd ixl6|/ \| cumulus linux | | 2 ixl1|-| switch 2| +-+ +---+ Trunks configured with ix ports behaved stable. Switch reboots, plugging out fibers etc. didnt harm anything. Switching to ixl based trunks changed the behavior. Here we ran into serious
relayd feature request
Hi, Today I found out that I was able to disable/enable hosts by name instead of id :) It would be nice if it worked when a host is mentioned in multiple redirects/tables (ie different ports): Id Type Name Avlblty Status 3 redirect mx-smtps active 3 table mx:465 active (2 hosts) 5 host mx1 100.00% up 6 host mx2 100.00% up 4 redirect mx-subm active 4 table mx:587 active (2 hosts) 7 host mx1 100.00% up 8 host mx2 100.00% up right now, relayctl host dis/en mx1, disables/enables it only in the first redirect. I've looked at the code but didn't find a clean way to make it happen... thanks in advance G
Re: sysupgrade (Was: Re: Kernel crash in OpenBSD 6.5)
In the past it was not uncommon for non-X programs in base to have dependencies in Xenocara. Are you certain that this is no longer so?
Re: sysupgrade (Was: Re: Kernel crash in OpenBSD 6.5)
Use the -n option to sysupgrade to not reboot after files are downloaded and verified. Then delete the unwanted tarballs as mentioned from /home/_sysupgrade/ and reboot. See sysupgrade(8): https://man.openbsd.org/sysupgrade > On Aug 1, 2019, at 7:31 AM, Antal Ispanovity wrote: > > 2019-08-01 8:08 GMT+02:00, Harald Dunkel : >> Hi folks, >> >>> On 7/30/19 3:08 PM, Hrvoje Popovski wrote: >>> >>> try to update both boxes to latest snapshot at least because in snapshot >>> you have excellent tool called sysupgrade ... you will love it :) >>> >>> with this tool you can upgrade os to latest snapshot without any problem >>> over ssh :) >>> >> This is cool. >> >> Due to space and speed restrictions (compact flash card) and to reduce >> downtime I would like to avoid the games and the Xwindow "balast" on my >> gateways. Does sysupgrade recognize the tar balls that are already >> installed, or does it become a "sysinstall" in this case? > Iif I remember correctly it doesn't. Someone solved this by removing > the unnecessary tarballs from the _sysupgrade folder and performed the > upgrade after it. >> >> Sorry for asking, but the man page https://man.openbsd.org/sysupgrade >> doesn't tell. >> >> >> Thanx in advance >> Harri >> >> >
Re: sysupgrade (Was: Re: Kernel crash in OpenBSD 6.5)
2019-08-01 8:08 GMT+02:00, Harald Dunkel : > Hi folks, > > On 7/30/19 3:08 PM, Hrvoje Popovski wrote: >> >> try to update both boxes to latest snapshot at least because in snapshot >> you have excellent tool called sysupgrade ... you will love it :) >> >> with this tool you can upgrade os to latest snapshot without any problem >> over ssh :) >> > This is cool. > > Due to space and speed restrictions (compact flash card) and to reduce > downtime I would like to avoid the games and the Xwindow "balast" on my > gateways. Does sysupgrade recognize the tar balls that are already > installed, or does it become a "sysinstall" in this case? Iif I remember correctly it doesn't. Someone solved this by removing the unnecessary tarballs from the _sysupgrade folder and performed the upgrade after it. > > Sorry for asking, but the man page https://man.openbsd.org/sysupgrade > doesn't tell. > > > Thanx in advance > Harri > >
Re: problem to copy a (possibly large) file over a network device
Rudolf Sykora writes: > In one terminal: > ;tar -cf - www | pv | nc localhost 7000 > > In another terminal: > ;nc -l 7000 | pv | tar -xpf - are there some settings which I could try to change? (Some files are >10GB, if that matters.) Thanks Ruda
sysupgrade (Was: Re: Kernel crash in OpenBSD 6.5)
Hi folks, On 7/30/19 3:08 PM, Hrvoje Popovski wrote: try to update both boxes to latest snapshot at least because in snapshot you have excellent tool called sysupgrade ... you will love it :) with this tool you can upgrade os to latest snapshot without any problem over ssh :) This is cool. Due to space and speed restrictions (compact flash card) and to reduce downtime I would like to avoid the games and the Xwindow "balast" on my gateways. Does sysupgrade recognize the tar balls that are already installed, or does it become a "sysinstall" in this case? Sorry for asking, but the man page https://man.openbsd.org/sysupgrade doesn't tell. Thanx in advance Harri
Re: How to debug hanging machines / proc: table is full
On Wed, Jul 31, 2019 at 04:20:12PM +, Visa Hankala wrote: > On Wed, Jul 31, 2019 at 05:46:08PM +0200, Raimo Niskanen wrote: > > I have enabled Witness, it went so-so. We'll see what it catches. > > > > I downloaded 6.5 amd64 src.tar.gz and sys.tar.gz, unpacked them, > > applied all patches for stable 001-006 and built a kernel with: > > include "arch/amd64/conf/GENERIC" > > optionMULTIPROCESSOR > > optionMP_LOCKDEBUG > > optionWITNESS > > > > Then I activated in /etc/sysctl.conf: > > ddb.console=1 > > kern.witness.locktrace=1 > > kern.witness.watch=3 > > > > For fun, I pressed Ctrl+Alt+Esc at the console, got a ddb> prompt and typed > > "show witness". It printed lots of info, I scrolled down to the end, but > > during the printout there was an UVM fault: > > > > Spin locks: > > /usr/src/sys/ > > : > > bla bla bla > > : > > uvm_fault(0x81e03b50, 0x800022368360, 0, 1) -> e > > kernel: page fault trap, code=0 > > Faulted in DDB: continuing... > > The output of "show witness" is unlikely to be useful in your case. > It is more of a tool for debugging witness. You can ignore it. > However, "show all locks" might display interesting information > after a witness-related panic. Ok, great! It is just that an uvm_fault during show witness felt like a bad thing... -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
