Re: suspend-to-RAM intel-x86 issues and tests

[David Brownlee <abs%absd.org@localhost>]

On Tue, 23 Oct 2018 at 22:31, Riccardo Mottola
<riccardo.mottola%libero.it@localhost> wrote:
>
> Hi,
>
> David Brownlee wrote:
>
> >
> >> I don't have a setup to build there, I am trying RelEng kernels.
> >> I could use those to bisect - but I have worse news. Even NetBSD 8
> >> release is actually unreliable. So it did work, but I tried again and
> >> got a black screen... so it is not a repeatable reference.
> >> Darn :) Would have made things easier.
> >
> > If you have any kind of box (even Windows or Mac) that you could use
> > for testing builds it is likely to be very helpful.
>
> Sorry, did not get fully what do you mean. What should I use that Win or
> Mac box for? I am full of "boxen" :) Including several NetBSD ones.

You mentioned that you didn't have a setup to build NetBSD - I was
just trying to note
that NetBSD can be cross built from other boxes, so if you have a
bigger machines with
sufficient disk and cpu which doesn't happen to run NetBSD it can make
a convenient
build box.

> > As a random test idea on the Thinkpad - maybe go into the BIOS and try
> > disabling as much hardware there as possible to see if that helps the
> > suspend/resume. It probably wont affect anything, but should be easy
> > to test and if it does then it gives some useful information.
>
> I took the T30, the P4 with ATI Radeon, which looked promising since it
> at least spits out some kernel messages before dieing!
>
> I went into the BIOS and disabled: Strange "wake on lan or flash on LAN
> options", Serial Port, Parallel Port, Infrared Port, USB port, legacy
> floppy drives (not present anyway), even the TrackPoint. I don't have
> the Security chip, so it is disabled by default.
> I even disabled Intel Speed Step (I hope it does no harm)
>
> So pretty much anything I could find!
>
> Then I booted a couple of days old generic kernel.
> There I disabled more stuff:
> - isa
> - fxp
> - radeon
> - audio
>
>
> should be quite barebones!!! Below a dmesg of such "bare" configuration.
>
> Yet... it crashes on sleep with the already stated error
>
> trap_tss() at netbsd:trap_tss
> --- trap via task gate ---
> netbsd:cpu_info_primary:
> cpu0 End traceback...

Ah - it was a "probably wont affect anything, but easy to test and
could have given useful information" :/

Thanks

David