Re: 7.0 Release amd64 Crashes after booting on ACER Aspire
I ran the disable command. While it was reordering the kernel it shutoff. This time though with no temperature messages to the console. I also tried to disable amdgpu, and got the same results. On Sun, Oct 17, 2021 at 11:29:28PM +0100, Stuart Henderson wrote: Please boot with "disable acpitz" like you showed in the attached file, and generate a bug report by running sendbug as root (if you need to send from a different system, redirect sendbug -P and move the file across and edit/send), running it as root will include an encoded copy of the acpi tables which may help identify what's wrong. -- Sent from a phone, apologies for poor formatting. On 17 October 2021 22:06:09 Jon Fineman wrote: I started a new report since I have newer info. The old thread was: https://marc.info/?l=openbsd-bugs=159780203127790=2 Again since it shuts down I can't generate a bug report from the laptop. The original thread has a dmesg from 6.6. In 7.0 I get the same behavior but now I get an added message to the console: acpitz0: critical temperature exceeded 127c, shutting down I have attached the messages file from /var/log (it just contains the same messages about failing to load firmware and amdgpu. I attached a pic of the console. My laptop is not running hot. I ran 6.6 on it fine and since Aug of 2020 I have been running Arch on it fine. --
iwm sporadically disconnects since OpenBSD 7.0
>Synopsis: iwm sporadically disconnects WI-FI connection >Category: system >Environment: System : OpenBSD 7.0 Details : OpenBSD 7.0 (GENERIC.MP) #232: Thu Sep 30 14:25:29 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 >Description: Since the upgrade from OpenBSD 6.9 to 7.0 a few hours ago, my WI-FI connection dies every few minutes. It feels like it dies when there is a lot of network traffic (`pkg_add -u` or when watching video streams). The connection automatically resumes after ~1min. My dmesg shows this: iwm0: fatal firmware error iwm0: could not remove MAC context (error 35) iwm0: device timeout iwm0: device timeout iwm0: device timeout iwm0: device timeout dmesg: OpenBSD 7.0 (GENERIC.MP) #232: Thu Sep 30 14:25:29 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 12549996544 (11968MB) avail mem = 12153618432 (11590MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x9cbfd000 (66 entries) bios0: vendor LENOVO version "JBET69WW (1.33 )" date 03/15/2018 bios0: LENOVO 20BUS02F0Y acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT PCCT SSDT TCPA SSDT UEFI MSDM BATB FPDT UEFI acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz, 2195.23 MHz, 06-3d-04 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,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.2.4.1.1.1, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz, 2194.93 MHz, 06-3d-04 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz, 2194.93 MHz, 06-3d-04 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz, 2194.93 MHz, 06-3d-04 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP1) acpiprt3 at acpi0: bus 3 (EXP2) acpiprt4 at acpi0: bus -1 (EXP3) acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpipci0 at acpi0 PCI0: 0x 0x0011
Re: 7.0 Release amd64 Crashes after booting on ACER Aspire
Please boot with "disable acpitz" like you showed in the attached file, and generate a bug report by running sendbug as root (if you need to send from a different system, redirect sendbug -P and move the file across and edit/send), running it as root will include an encoded copy of the acpi tables which may help identify what's wrong. -- Sent from a phone, apologies for poor formatting. On 17 October 2021 22:06:09 Jon Fineman wrote: I started a new report since I have newer info. The old thread was: https://marc.info/?l=openbsd-bugs=159780203127790=2 Again since it shuts down I can't generate a bug report from the laptop. The original thread has a dmesg from 6.6. In 7.0 I get the same behavior but now I get an added message to the console: acpitz0: critical temperature exceeded 127c, shutting down I have attached the messages file from /var/log (it just contains the same messages about failing to load firmware and amdgpu. I attached a pic of the console. My laptop is not running hot. I ran 6.6 on it fine and since Aug of 2020 I have been running Arch on it fine.
Re: iwm sporadically disconnects since OpenBSD 7.0
On Mon, Oct 18, 2021 at 12:07:43AM +0200, Stefan Sperling wrote: > On Sun, Oct 17, 2021 at 08:46:47PM +0200, Richard Ulmer wrote: > > >Synopsis: iwm sporadically disconnects WI-FI connection > > >Category: system > > >Environment: > > System : OpenBSD 7.0 > > Details : OpenBSD 7.0 (GENERIC.MP) #232: Thu Sep 30 14:25:29 MDT > > 2021 > > > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > Architecture: OpenBSD.amd64 > > Machine : amd64 > > >Description: > > Since the upgrade from OpenBSD 6.9 to 7.0 a few hours ago, my WI-FI > > connection dies every few minutes. It feels like it dies when there is a > > lot of network traffic (`pkg_add -u` or when watching video streams). > > The connection automatically resumes after ~1min. My dmesg shows this: > > iwm0: fatal firmware error > > iwm0: could not remove MAC context (error 35) > > iwm0: device timeout > > iwm0: device timeout > > iwm0: device timeout > > iwm0: device timeout > > Please try a -current kernel. There have been several improvements since > the 7.0 release tag. Perhaps your problem has already been fixed? > > If the problem still occurs, please enable 'ifconfig iwm0 debug' and > wait for it to trigger again. The driver should then print additional > messages to /var/log/messages providing more context about the error. Something else you could try is downgrading the firmware image. This can be done without patching the kernel by swapping out the firmware file: mv /etc/firmware/iwm-7265D-29 /etc/firmware/iwm-7265D-29.orig cp /etc/firmware/iwm-7265-17 /etc/firmware/iwm-7265D-29 The 7265-17 image was used in OpenBSD 6.9. The 7265D-29 image is used in OpenBSD 7.0. -current now defaults to the 7265-17 again, because we found out (a bit too late for the release) that the 7265D-29 firmware was causing issues.
Re: iwm sporadically disconnects since OpenBSD 7.0
On Sun, Oct 17, 2021 at 08:46:47PM +0200, Richard Ulmer wrote: > >Synopsis:iwm sporadically disconnects WI-FI connection > >Category:system > >Environment: > System : OpenBSD 7.0 > Details : OpenBSD 7.0 (GENERIC.MP) #232: Thu Sep 30 14:25:29 MDT > 2021 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > >Description: > Since the upgrade from OpenBSD 6.9 to 7.0 a few hours ago, my WI-FI > connection dies every few minutes. It feels like it dies when there is a > lot of network traffic (`pkg_add -u` or when watching video streams). > The connection automatically resumes after ~1min. My dmesg shows this: > iwm0: fatal firmware error > iwm0: could not remove MAC context (error 35) > iwm0: device timeout > iwm0: device timeout > iwm0: device timeout > iwm0: device timeout Please try a -current kernel. There have been several improvements since the 7.0 release tag. Perhaps your problem has already been fixed? If the problem still occurs, please enable 'ifconfig iwm0 debug' and wait for it to trigger again. The driver should then print additional messages to /var/log/messages providing more context about the error. Thanks!
Re: mg: permissions are reset when saving the file
On 2021-10-17 16:17 +02, Hiltjo Posthuma wrote: > Hi, > > I noticed in mg when changing permissions while editing a file it will not > retain the permissions. This is how emacs behaves as well. > > Steps to reproduce: > > * mg newscript > * Write something and save the file. > * Outside mg (while keeping mg open) in some other terminal do: > chmod +x newscript at this point you can do M-x revert-buffer and mg(1) will learn the new permissions. > * While keeping mg open write something in mg and save the file again. > * Result: the permissions are reset (without +x). > > -- > Kind regards, > Hiltjo > -- I'm not entirely sure you are real.
Re: OpenBSD 7.0 installer bug
On Sun, Oct 17, 2021 at 01:29:23PM +, Klemens Nanni wrote:
> On Sun, Oct 17, 2021 at 11:33:48AM +0300, Pasi-Pekka Karppinen wrote:
> > When doing a fresh install and you are at the point where you are
> > configuring a wireless network, the installer is asking you to provide a
> > WPA/WPA2 security passphrase for the wireless network - if your WPA/WPA2
> > passphrase starts with a “!” character (exclamation mark), the installer
> > won’t accept the passphrase.
>
> It has been like this forever, i.e. this is not 7.0 specific.
>
> I don't think it is worth adding an exception for this particular
> question as it'd break the expectation of `!'s behaviour, seems rare
> enough to accept and would add needless complexity.
>
> Not being able to download sets, on the other hand, can be bummer
> during install/upgrade, but then again full offline install images as
> well as sysupgrade(8) are available, so that can be worked around.
Then again, WEP/WPA passphrases could be treated like user passwords.
Simple code change, but behaviour would change, i.e. the passphrase is
not echoed anymore.
You can try the following diff for that. I have not tested it yet
(no setup to install over wifi here).
Either apply the diff and build your favourite install medium or try
this quick hack in a ramdisk shell before you start to see if that
prompts, connects and installs hostname.* just fine:
sed -i '/WPA passphrase/ { s/until/password/ ; s/$/ ; resp=$_password/ ; }'
/install.sub
Index: install.sub
===
RCS file: /cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.1180
diff -u -p -r1.1180 install.sub
--- install.sub 17 Oct 2021 13:20:46 - 1.1180
+++ install.sub 17 Oct 2021 17:35:15 -
@@ -1245,19 +1245,19 @@ ieee80211_config() {
quote nwid "$_nwid" >>$_hn
break
;;
- ?-[Ww]) ask_until "WEP key? (will echo)"
+ ?-[Ww]) ask_until "WEP key?"
# Make sure ifconfig accepts the key.
- if _err=$(ifconfig $_if nwid "$_nwid" nwkey
"$resp" 2>&1) &&
+ if _err=$(ifconfig $_if nwid "$_nwid" nwkey
"$_password" 2>&1) &&
[[ -z $_err ]]; then
- quote nwid "$_nwid" nwkey "$resp" >>$_hn
+ quote nwid "$_nwid" nwkey "$_password"
>>$_hn
break
fi
echo "$_err"
;;
- 1-[Pp]) ask_until "WPA passphrase? (will echo)"
+ 1-[Pp]) ask_password "WPA passphrase?"
# Make sure ifconfig accepts the key.
- if ifconfig $_if nwid "$_nwid" wpakey "$resp";
then
- quote nwid "$_nwid" wpakey "$resp"
>>$_hn
+ if ifconfig $_if nwid "$_nwid" wpakey
"$_password"; then
+ quote nwid "$_nwid" wpakey "$_password"
>>$_hn
break
fi
;;
Re: 7.0 ports.tar.gz missing leading ports/ directory name
On Fri, Oct 15, 2021 at 07:48:42AM +0100, Stuart Henderson wrote: > You won't get a full ports tree from this file anyway, some of the filenames > are too long for our tar implementation. Running "cvs -d > anoncvs@some.mirror:/cvs up -Pd" after unpacking should fill in the missing > files. > Yes, I have had that problem when trying to do disk duplication as outlined in the FAQ, gtar does the trick, but I have just used the dump method instead. Is it a difficult task to fix our tar? Should the tar method be removed from the disk duplication instructions in the FAQ? Perhaps just a note warning about the problem there? Chris Bennett
Re: OpenBSD 7.0 installer bug
> On Oct 17, 2021, at 9:20 AM, Pasi-Pekka Karppinen wrote: > > When doing a fresh install and you are at the point where you are > configuring a wireless network, the installer is asking you to provide a > WPA/WPA2 security passphrase for the wireless network - if your WPA/WPA2 > passphrase starts with a “!” character (exclamation mark), the installer > won’t accept the passphrase. Have you tried using double quotes around the password? Just curious if it works, I have no idea if it would.
mg: permissions are reset when saving the file
Hi, I noticed in mg when changing permissions while editing a file it will not retain the permissions. Steps to reproduce: * mg newscript * Write something and save the file. * Outside mg (while keeping mg open) in some other terminal do: chmod +x newscript * While keeping mg open write something in mg and save the file again. * Result: the permissions are reset (without +x). -- Kind regards, Hiltjo
Re: OpenBSD 7.0 installer bug
On Sun, Oct 17, 2021 at 11:33:48AM +0300, Pasi-Pekka Karppinen wrote: > When doing a fresh install and you are at the point where you are configuring > a wireless network, the installer is asking you to provide a WPA/WPA2 > security passphrase for the wireless network - if your WPA/WPA2 passphrase > starts with a “!” character (exclamation mark), the installer won’t accept > the passphrase. It has been like this forever, i.e. this is not 7.0 specific. I don't think it is worth adding an exception for this particular question as it'd break the expectation of `!'s behaviour, seems rare enough to accept and would add needless complexity. Not being able to download sets, on the other hand, can be bummer during install/upgrade, but then again full offline install images as well as sysupgrade(8) are available, so that can be worked around.
