Re: iwm sporadically disconnects since OpenBSD 7.0
Stefan Sperling wrote: > On Mon, Oct 18, 2021 at 07:14:57PM +0200, Richard Ulmer wrote: > > > 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. > > > > I did this and my WI-FI seems to be stable again. Thanks a lot! > > OK, good to know. > > 7265D works with the linux iwlwifi driver and it worked fine when I tested > it with 7265 iwm(4) in an x250 thinkpad with a pepwave access point. Later, > some people reported various failures that all looked slightly different. > It took a while until Landry bisected the problem down to the change in > firmware version. The original problem reports we received looked like > badly connected antennas, hardware issues, or 802.11 protocol interop > problems, and all this led us down several wrong paths in our investigation. > Which is why it took some time until this workaround was found. > > > > 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. > > > > I have never set up a -current OpenBSD, so I'm not comfortable with > > this. Sorry. I could however try to catch the error with 'ifconfig iwm0 > > debug' enabled. Would that help you, even if I'm not on -current? > > Not really. There is nothing the driver does differently so any failure > messages we can see in dmesg will just be a symptom of the underlying issue. > Somehow 7265D firmware is unhappy with our driver in some cases. > It's not high on my list of things to fix, given that development time is > always limited, a workaround is known, and there are more interesting > problems to solve. But it would be good to fix this eventually, since the > 7265D firmware looks better on paper since it has received more maintenance > from Intel than the older ones, which might include security fixes for > all we can tell (intel doesn't publish any wifi firmware changelogs). OK, thanks for the info and thanks for your work! I'll leave the problem be for now, since the workaround works well for me. If I happen to set up a -current installation in the future, I'll give 'ifconfig iwm0 debug' a shot and let you know.
Re: 7.0 Release amd64 Crashes after booting on ACER Aspire
.Hi, if it's helpful, I had a similar experience with a laptop with an A10-9600P. The solution I found was to disable the kernel piixpm driver. This driver underwent modifications 20 months ago. I also sent information to this list with the problem when I found it. Manuel Blanca On Mon, Oct 18, 2021 at 10:52:56AM +0100, Stuart Henderson wrote: > Possibly. Also if you could download kernels from the intermediate releases > on the 6.6 system (ftp.eu.openbsd.org has an archive of many versions) and > save them e.g. to /bsd.67, /bsd.68 and try booting them, try to find which > version the problem started with? > > > On 2021/10/18 05:47, Jon Fineman wrote: > > I still have an image for 6.6. Would a sendbug from 6.6 be a help? > > > > > > On Mon, Oct 18, 2021 at 09:58:47AM +0100, Stuart Henderson wrote: > > > I guess the embedded controller is actually shutting the machine down > > > then, > > > rather than just a spurious error behind reported. > > > > > > -- > > > Sent from a phone, apologies for poor formatting. > > > > > > > > > On 18 October 2021 00:44:09 Jon Fineman wrote: > > > > > > > > > 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 > > > theconsole: > > > acpitz0: critical temperature exceeded 127c, shutting down > > > > > > I have attached the messages file from /var/log (it just contains > > > thesame 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 > > > of2020 I have been running Arch on it fine. > > > > > > > > > > > > > > > -- > > > > > > > > > > --
Re: iwm sporadically disconnects since OpenBSD 7.0
> 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. I did this and my WI-FI seems to be stable again. Thanks a lot! > 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. I have never set up a -current OpenBSD, so I'm not comfortable with this. Sorry. I could however try to catch the error with 'ifconfig iwm0 debug' enabled. Would that help you, even if I'm not on -current?
Re: iwm sporadically disconnects since OpenBSD 7.0
On Mon, Oct 18, 2021 at 07:14:57PM +0200, Richard Ulmer wrote: > > 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. > > I did this and my WI-FI seems to be stable again. Thanks a lot! OK, good to know. 7265D works with the linux iwlwifi driver and it worked fine when I tested it with 7265 iwm(4) in an x250 thinkpad with a pepwave access point. Later, some people reported various failures that all looked slightly different. It took a while until Landry bisected the problem down to the change in firmware version. The original problem reports we received looked like badly connected antennas, hardware issues, or 802.11 protocol interop problems, and all this led us down several wrong paths in our investigation. Which is why it took some time until this workaround was found. > > 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. > > I have never set up a -current OpenBSD, so I'm not comfortable with > this. Sorry. I could however try to catch the error with 'ifconfig iwm0 > debug' enabled. Would that help you, even if I'm not on -current? Not really. There is nothing the driver does differently so any failure messages we can see in dmesg will just be a symptom of the underlying issue. Somehow 7265D firmware is unhappy with our driver in some cases. It's not high on my list of things to fix, given that development time is always limited, a workaround is known, and there are more interesting problems to solve. But it would be good to fix this eventually, since the 7265D firmware looks better on paper since it has received more maintenance from Intel than the older ones, which might include security fixes for all we can tell (intel doesn't publish any wifi firmware changelogs).
Re: 7.0 Release amd64 Crashes after booting on ACER Aspire
Possibly. Also if you could download kernels from the intermediate releases on the 6.6 system (ftp.eu.openbsd.org has an archive of many versions) and save them e.g. to /bsd.67, /bsd.68 and try booting them, try to find which version the problem started with? On 2021/10/18 05:47, Jon Fineman wrote: > I still have an image for 6.6. Would a sendbug from 6.6 be a help? > > > On Mon, Oct 18, 2021 at 09:58:47AM +0100, Stuart Henderson wrote: > > I guess the embedded controller is actually shutting the machine down then, > > rather than just a spurious error behind reported. > > > > -- > > Sent from a phone, apologies for poor formatting. > > > > > > On 18 October 2021 00:44:09 Jon Fineman wrote: > > > > > >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 > > theconsole: > >acpitz0: critical temperature exceeded 127c, shutting down > > > >I have attached the messages file from /var/log (it just contains > > thesame 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 > > of2020 I have been running Arch on it fine. > > > > > > > > > >-- > > > > > > --
Re: 7.0 Release amd64 Crashes after booting on ACER Aspire
I still have an image for 6.6. Would a sendbug from 6.6 be a help? On Mon, Oct 18, 2021 at 09:58:47AM +0100, Stuart Henderson wrote: I guess the embedded controller is actually shutting the machine down then, rather than just a spurious error behind reported. -- Sent from a phone, apologies for poor formatting. On 18 October 2021 00:44:09 Jon Fineman wrote: 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. -- --
Re: 7.0 Release amd64 Crashes after booting on ACER Aspire
I guess the embedded controller is actually shutting the machine down then, rather than just a spurious error behind reported. -- Sent from a phone, apologies for poor formatting. On 18 October 2021 00:44:09 Jon Fineman wrote: 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. --
Re: mg: permissions are reset when saving the file
On Sun, Oct 17, 2021 at 08:37:51PM +0200, Florian Obser wrote: > 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. OK, thank you -- Kind regards, Hiltjo
