> From: Peter Nicolai Mathias Hansteen
> Date: Sat, 8 May 2021 13:15:10 +0200
>
> > 7. mai 2021 kl. 23:28 skrev Mark Kettenis :
> >>
> >> Yeah, nothing changed.
> >
> > That said, can you try the attached diff? Again I'm curious if
> > halt -p works with this or not.
>
> Yes, of course,
> 7. mai 2021 kl. 23:28 skrev Mark Kettenis :
>>
>> Yeah, nothing changed.
>
> That said, can you try the attached diff? Again I'm curious if
> halt -p works with this or not.
Yes, of course, excellent!
And a few minutes later, I can report that with that patch applied, halt -p
works as
> Date: Fri, 7 May 2021 21:04:19 +0200 (CEST)
> From: Mark Kettenis
>
> > Date: Fri, 7 May 2021 10:24:19 +0200
> > From: "Peter N. M. Hansteen"
> >
> > On Thu, May 06, 2021 at 05:00:47PM +0200, Peter N. M. Hansteen wrote:
> > > Hi Mark,
> > >
> > > On Thu, May 06, 2021 at 04:30:00PM +0200,
> Date: Fri, 7 May 2021 10:24:19 +0200
> From: "Peter N. M. Hansteen"
>
> On Thu, May 06, 2021 at 05:00:47PM +0200, Peter N. M. Hansteen wrote:
> > Hi Mark,
> >
> > On Thu, May 06, 2021 at 04:30:00PM +0200, Mark Kettenis wrote:
> > > >
> > > > Are there other tests I could usefully perform for
Hi Mark,
On Thu, May 06, 2021 at 04:30:00PM +0200, Mark Kettenis wrote:
> >
> > Are there other tests I could usefully perform for this one?
>
> Not sure. The BIOS on this machine is kinda broken. It adbertises
> itself as "hardware reduced" ACPI (something usually seen on arm64
> machines)
Hi Mark,
Are there other tests I could usefully perform for this one?
All the best,
Peter
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network
> Date: Thu, 6 May 2021 16:17:51 +0200
> From: "Peter N. M. Hansteen"
>
> Hi Mark,
>
> Are there other tests I could usefully perform for this one?
Not sure. The BIOS on this machine is kinda broken. It adbertises
itself as "hardware reduced" ACPI (something usually seen on arm64
machines)
> Date: Mon, 3 May 2021 23:06:58 +0200
> From: "Peter N. M. Hansteen"
> Cc: bugs@openbsd.org
> Content-Type: multipart/mixed; boundary="xA/hR9rv41MU9mZo"
> Content-Disposition: inline
>
>
> [1:text/plain Hide]
>
> Hi Mark,
>
> On Mon, May 03, 2021 at 07:00:44PM +0200, Mark Kettenis wrote:
> >
Further info (screen shots) - today during a lengthy rsync it seemed the
screen saver kicked in but X crashed right after and then this sequence
happened:
https://www.bsdly.net/~peter/20210503_164555.jpg
https://www.bsdly.net/~peter/20210503_164607.jpg
Hi Peter,
Here is a small diff. Two questions:
1. Does the machine powerdown if you do halt -p with this diff?
2. Does the diff fix the crashes?
Thanks,
Mark
Index: dev/acpi/acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
> 2. mai 2021 kl. 19:54 skrev Mark Kettenis :
>
>
> Can you file a proper sendbug report for this machine?
>
>
I just did a sendbug. It went by really fast so I hope it actually contains the
required information.
All the best,
Peter
—
Peter N. M. Hansteen, member of the first RFC 1149
On Sun, May 02, 2021 at 04:02:17PM -0400, Bryan Steele wrote:
> On Sun, May 02, 2021 at 09:51:13PM +0200, Peter Nicolai Mathias Hansteen
> wrote:
> >
> >
> > > 2. mai 2021 kl. 19:54 skrev Mark Kettenis :
> > >
> > >
> > > Can you file a proper sendbug report for this machine?
> > >
> > >
>
> Date: Sun, 2 May 2021 13:05:49 +0200
> From: "Peter N. M. Hansteen"
>
> On Sat, May 01, 2021 at 07:58:20PM +0200, Peter N. M. Hansteen wrote:
> > On Fri, Apr 30, 2021 at 09:59:14PM +1000, Jonathan Gray wrote:
> > >
> > > Or perhaps boot -c and disable acpicpu* if that doesn't break anything.
On Sat, May 01, 2021 at 07:58:20PM +0200, Peter N. M. Hansteen wrote:
> On Fri, Apr 30, 2021 at 09:59:14PM +1000, Jonathan Gray wrote:
> >
> > Or perhaps boot -c and disable acpicpu* if that doesn't break anything.
>
> Doing the boot -c and disable acpicpu* did enable the thing to boot, so
> for
On Fri, Apr 30, 2021 at 09:59:14PM +1000, Jonathan Gray wrote:
>
> Or perhaps boot -c and disable acpicpu* if that doesn't break anything.
Doing the boot -c and disable acpicpu* did enable the thing to boot, so
for now it's running with a config -e'd kernel.
The next hurdle is that the iwm
On Fri, Apr 30, 2021 at 12:00:05PM +1000, Jonathan Gray wrote:
>
> If you can build a kernel on another machine try
>
> Index: sys/dev/acpi/acpi.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
> retrieving revision 1.397
> diff
On Fri, Apr 30, 2021 at 01:51:11PM +0200, Peter N. M. Hansteen wrote:
> On Fri, Apr 30, 2021 at 12:00:05PM +1000, Jonathan Gray wrote:
> >
> > If you can build a kernel on another machine try
> >
> > Index: sys/dev/acpi/acpi.c
> >
On Thu, Apr 29, 2021 at 10:27:49PM +0200, Peter Nicolai Mathias Hansteen wrote:
> I just spent the evening trying to work around an odd error that happens
> after an apparently straightforward install on a new laptop.
>
> The most useful info I can offer is that the install proceeds with no
>
18 matches
Mail list logo
