On Sun, 15 Aug 2021 at 21:31, John Mellor wrote:
>
> Just an update:
>
> The type of failure that I consistently kept seeing in the logs was
> illegal addressing in high memory during shutdown. The failing address
> always looked like a couple of stuck high address bits, which was
> unlikely
On Sun, 2021-08-15 at 20:30 -0400, John Mellor wrote:
> This outcome is a huge relief, but would seem to show that something
> in
> the ACPI code is not checking for valid addresses. The newer ACPI
> firmware is no longer providing bogus addresses, and the problem has
> gone away -- something
On 2021-07-28 1:12 a.m., Chris Murphy wrote:
On Tue, Jul 27, 2021 at 3:36 PM old sixpack13 wrote:
...
is your GPU from intel ?
if so:
- I get it too, sometimes while browsing with FF.
- Crtl+Alt+F3 to get a console (?) and do dmesg => ...GPU Crash dump ... GPU
hang...
+++ EDIT +++
I should
On 7/28/21 8:07 AM, John Mellor wrote:
Hi Chris,
I can only describe my experiences. On this Lenovo P300 machine, I
have installed btrfs on a consumer drive, 2 enterprise drives, a
matching pair of enterprise drives in btrfs RAID-1, and an ssd. All
are single-ended SATA. I have also
On 2021-07-28 1:12 a.m., Chris Murphy wrote:
On Tue, Jul 27, 2021 at 3:36 PM old sixpack13 wrote:
...
is your GPU from intel ?
if so:
- I get it too, sometimes while browsing with FF.
- Crtl+Alt+F3 to get a console (?) and do dmesg => ...GPU Crash dump ... GPU
hang...
+++ EDIT +++
I should
> On Tue, Jul 27, 2021 at 3:36 PM old sixpack13 wrote:
>
> There shouldn't be such a thing as file system corruption following
> forced power off. It's sufficiently well tested on ext4, xfs, and
...
thanks chris for detailed info's, it helps to lower my fear.
but as I mentioned in my last
> On 2021-07-27 5:35 p.m., old sixpack13 wrote:
> Yeah, its a
> Lenovo P300 with an i915 GPU on a 4th-gen i5, on an
> IBM/Lenovo motherboard from 2016. I'm just thinking - what would happen
> if I put in a cheap PCIe video card and disabled the intel one...
> Nope, at that point under Gnome you
On Tue, Jul 27, 2021 at 3:36 PM old sixpack13 wrote:
>
> ...
> > is your GPU from intel ?
> > if so:
> > - I get it too, sometimes while browsing with FF.
> > - Crtl+Alt+F3 to get a console (?) and do dmesg => ...GPU Crash dump ...
> > GPU hang...
>
> +++ EDIT +++
> I should have read the first
On 2021-07-27 5:35 p.m., old sixpack13 wrote:
...
is your GPU from intel ?
if so:
- I get it too, sometimes while browsing with FF.
- Crtl+Alt+F3 to get a console (?) and do dmesg => ...GPU Crash dump ... GPU
hang...
+++ EDIT +++
I should have read the first thread again: it's an Intel GPU.
...
> is your GPU from intel ?
> if so:
> - I get it too, sometimes while browsing with FF.
> - Crtl+Alt+F3 to get a console (?) and do dmesg => ...GPU Crash dump ... GPU
> hang...
+++ EDIT +++
I should have read the first thread again: it's an Intel GPU.
anyway, after Crtl+Alt+F3 you should
> On 2021-07-27 9:08 a.m., old sixpack13 wrote:
>
>
> On a hunch, I disabled the Lenovo deep C-state handling in the BIOS,
> reinstalled using BTRFS again and mostly recovered from backups.
...
If I get it right, a new install fixed it for you ?
>
> I have had the GUI lockup twice,
On 2021-07-27 9:08 a.m., old sixpack13 wrote:
ping Chris Murphy, John Mellor
is this theme solved and if so, how
I ran the extended built-in BIOS diagnostics on this Lenovo P300 machine
again last week for half a day, and no faults were found. I also ran the
GTKstresstest and
ping Chris Murphy, John Mellor
is this theme solved and if so, how ?
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
OK I'm skipping ahead because I got an email offlist from John with
the journal. Hopefully he will post a pastebin or use file sharing
service to share the journal so others can pitch in on the diagnosis.
I'm seeing quite a lot of gaps in the time stamps (why I like
monotonic time, makes such
> On Sun, Jul 18, 2021 at 11:12 AM Joe Zeff wrote:
> >
> > On 7/18/21 7:38 AM, John Mellor wrote:
Oh nice, the previous email is meant for John, not Joe.
--
Chris Murphy
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an
On Sun, Jul 18, 2021 at 11:12 AM Joe Zeff wrote:
>
> On 7/18/21 7:38 AM, John Mellor wrote:
> > Here is the top of the current systemd-analyse blame output:
> >
> > $ systemd-analyze blame
> > 27.625s plymouth-quit-wait.service
This counts the time to get to the login window, plymouth itself
On 7/18/21 3:01 PM, old sixpack13 wrote:
I'll test to disable plymouth on my brother's box. He is also suffering from
long boot times on an aged Intel i3.
Just disable for now, no need to mask, and if it doesn't help, it's
easier to undo. Keep us informed either way.
> On 7/18/21 11:44 AM, old sixpack13 wrote:
>
> Oddly, it has a man page that tells us that it prevents logins during
> boot and shutdown while allowing them at other times. I was going to
> prove that plymouth-quit-wait.service wasn't needed by showing that I've
> disabled/masked it on this
On 7/18/21 11:44 AM, old sixpack13 wrote:
I'm unsure what systemd-user-sessions.service really is for. It's an binary
file !
Oddly, it has a man page that tells us that it prevents logins during
boot and shutdown while allowing them at other times. I was going to
prove that
> On 7/18/21 7:38 AM, John Mellor wrote:
>
> OK, here's where the trouble probably lies. If memory serves, the first
> one can be disabled and masked safely, and if not, I'm sure somebody
> will correct me.
I'm not sure if I'm able to correct you, but:
cat
On 7/18/21 7:38 AM, John Mellor wrote:
Here is the top of the current systemd-analyse blame output:
$ systemd-analyze blame
27.625s plymouth-quit-wait.service
21.726s udisks2.service
13.932s libvirtd.service
13.711s systemd-journal-flush.service
OK, here's where the trouble probably lies. If
On 2021-07-17 1:18 p.m., Joe Zeff wrote:
On 7/17/21 8:35 AM, John Mellor wrote:
What's wrong here? This is a fully up-to-date and stock F34 machine
with a good i5 processor, lots of RAM and a fast SSD, with a very
long and inexplicable time delay during boot. It appears to be idle
for 2
Saw on reddit about a 90 second stall.
https://www.reddit.com/r/Fedora/comments/ogr3pq/f34_boot_stalls_for_additional_90_seconds_on_a/
Edit /usr/lib/systemd/system/dbus-broker.service
and remove "sysinit.target" from the "After=" line so it is just
"After=dbus.socket"
Then do a 'dracut -fv
On 7/17/21 8:35 AM, John Mellor wrote:
What's wrong here? This is a fully up-to-date and stock F34 machine
with a good i5 processor, lots of RAM and a fast SSD, with a very long
and inexplicable time delay during boot. It appears to be idle for 2
minutes during every startup, with no known
What's wrong here? This is a fully up-to-date and stock F34 machine
with a good i5 processor, lots of RAM and a fast SSD, with a very long
and inexplicable time delay during boot. It appears to be idle for 2
minutes during every startup, with no known cause. This machine used to
boot in 8
25 matches
Mail list logo
