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
r
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
https://www.bsdly.net/~peter/20210503_164616
> 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:
> >
> 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) an
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 traffi
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) an
> 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
> 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, Mar
> 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 exp
> 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, excel
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
> co
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 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 -u
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 inter
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
> 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 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?
> >
> >
> I just did a sendbug. It went by really fast so I hope it actually contains
> the r
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?
> > >
> > >
> >
> 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 imp
19 matches
Mail list logo
