Request for explanation of error message

classic Classic list List threaded Threaded
74 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: Request for explanation of error message

Oliver Grawert
hi,
Am Montag, den 29.07.2019, 19:57 +0000 schrieb Mike Marchywka:

> >
> >
> > >
> > > How often do you get the PCI errors? Do you check dmesg often?
> > >
> > The PCI errors appear to be ongoing and incessant.
> This may be relevant,
>
> https://askubuntu.com/questions/771899/pcie-bus-error-severity-
> corrected
well, this points to:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1521173

which has a lot of debug info and potential things to try ...

yet ... bret, did you consider that a pci card simply came loose during
the replacement of the ram ? i think it is really suspicious that the
log spam started when you had your memory replaced ... the same
hardware worked fine without that error before so i start to doubt it
is actually a software error (typically such things dont come out of
the blue)

ciao
        oli

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Request for explanation of error message

Oliver Grawert
hi,
Am Montag, den 29.07.2019, 22:34 +0200 schrieb Oliver Grawert:

> typically such things dont come out of
> the blue

oh, and indeed it could also simply be that the shop guys did change a
BIOS setting they shouldnt have changed (the bug seems to talk about
"fastboot" and "aspm" ...

ciao
        oli
--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Request for explanation of error message

Bret Busby-2
In reply to this post by Oliver Grawert
On 30/07/2019, Oliver Grawert <[hidden email]> wrote:

> hi,
> Am Montag, den 29.07.2019, 19:57 +0000 schrieb Mike Marchywka:
>> >
>> >
>> > >
>> > > How often do you get the PCI errors? Do you check dmesg often?
>> > >
>> > The PCI errors appear to be ongoing and incessant.
>> This may be relevant,
>>
>> https://askubuntu.com/questions/771899/pcie-bus-error-severity-
>> corrected
>
> well, this points to:
>
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1521173
>
> which has a lot of debug info and potential things to try ...
>

I was previously referred to an "ask ubuntu" forum web page with a
question and solutions relating to this, and, I changed the two lines
in the grub file, to insert
pci=nomsi
then, whilst that stopped the growth of x-0.log , it did not stop the
error repeating in dmesg output, so I replaced the nomsi with noaer,
as was suggested, but, again, the same; the
x-0.log file appears to have stopped growing, but, the error message
is still incessantly repeating in dmesg.

> yet ... bret, did you consider that a pci card simply came loose during
> the replacement of the ram ? i think it is really suspicious that the
> log spam started when you had your memory replaced ... the same
> hardware worked fine without that error before so i start to doubt it
> is actually a software error (typically such things dont come out of
> the blue)
>

I think that this is wherer it would be really useful, if the error
messages, or, some sort of diagnostic, or, otherwise, some system
utility, identified what actual component is at the address, so,
whatever the PCI device is, it could be easily identified, thence, for
me to take the computer back to the shop, and say, "when the RAM was
replaced, an error message has been occurring, showing that the blerg
in the PCI slot, appears to have been dislodged - can you please fix
it", but, without knowing what PCI device is affected, all I can say,
is "something is wrong - please fix it", which is not helpful.

At the moment (and, for the last couple of months), my use of my right
hand, is significantly restricted - it is only a little more useful,
than if it would be tightly bandaged (which is about how it feels,
most of the time), so, for me to try to do anything with the inside of
the computer, would be more harmful than useful.

So, the problem of the incessantly growing log file, appears to be
restrained by a bandaid fix - whatever was incessantly writing to it,
appears to be broken,  shown by its hysterical panic, implemented by
its incessant writing to the file. That problem is not solved - only,
apparently, temporarily blocked, until it does it again.

> ciao
> oli
>


--
Bret Busby
Armadale
West Australia
..............

"So once you do know what the question actually is,
 you'll know what the answer means."
- Deep Thought,
 Chapter 28 of Book 1 of
 "The Hitchhiker's Guide to the Galaxy:
 A Trilogy In Four Parts",
 written by Douglas Adams,
 published by Pan Books, 1992

....................................................

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: Request for explanation of error message

Mike Marchywka
On Tue, Jul 30, 2019 at 06:21:09AM +0800, Bret Busby wrote:

> On 30/07/2019, Oliver Grawert <[hidden email]> wrote:
> > hi,
> > Am Montag, den 29.07.2019, 19:57 +0000 schrieb Mike Marchywka:
> >> >
> >> >
> >> > >
> >> > > How often do you get the PCI errors? Do you check dmesg often?
> >> > >
> >> > The PCI errors appear to be ongoing and incessant.
> >> This may be relevant,
> >>
> >> https://askubuntu.com/questions/771899/pcie-bus-error-severity-
> >> corrected
> >
> > well, this points to:
> >
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1521173
> >
> > which has a lot of debug info and potential things to try ...
> >
>
> I was previously referred to an "ask ubuntu" forum web page with a
> question and solutions relating to this, and, I changed the two lines
> in the grub file, to insert
> pci=nomsi
> then, whilst that stopped the growth of x-0.log , it did not stop the
> error repeating in dmesg output, so I replaced the nomsi with noaer,
> as was suggested, but, again, the same; the
> x-0.log file appears to have stopped growing, but, the error message
> is still incessantly repeating in dmesg.
>
> > yet ... bret, did you consider that a pci card simply came loose during
> > the replacement of the ram ? i think it is really suspicious that the
> > log spam started when you had your memory replaced ... the same
> > hardware worked fine without that error before so i start to doubt it
> > is actually a software error (typically such things dont come out of
> > the blue)
> >

There are a lot of boot options related to PCI and interrupts,

https://www.kernel.org/doc/html/v4.14/admin-guide/kernel-parameters.html
https://help.ubuntu.com/community/BootOptions

but I'm not even sure of the architecture at this point. Hardware generates
interrupts for all kind of reasons and someone has to either respond to
it or mask it. Configuration would be a possible cause rather than
hardware problem. You could try a few others and see if anything helps
but maybe you could try turning things off,  

https://askubuntu.com/questions/4546/how-do-i-turn-off-pci-devices

there is also setpci and other tools but if you don't already know
what you are doing it may take some learning.


 

>
> I think that this is wherer it would be really useful, if the error
> messages, or, some sort of diagnostic, or, otherwise, some system
> utility, identified what actual component is at the address, so,
> whatever the PCI device is, it could be easily identified, thence, for
> me to take the computer back to the shop, and say, "when the RAM was
> replaced, an error message has been occurring, showing that the blerg
> in the PCI slot, appears to have been dislodged - can you please fix
> it", but, without knowing what PCI device is affected, all I can say,
> is "something is wrong - please fix it", which is not helpful.
>
> At the moment (and, for the last couple of months), my use of my right
> hand, is significantly restricted - it is only a little more useful,
> than if it would be tightly bandaged (which is about how it feels,
> most of the time), so, for me to try to do anything with the inside of
> the computer, would be more harmful than useful.
>
> So, the problem of the incessantly growing log file, appears to be
> restrained by a bandaid fix - whatever was incessantly writing to it,
> appears to be broken,  shown by its hysterical panic, implemented by
> its incessant writing to the file. That problem is not solved - only,
> apparently, temporarily blocked, until it does it again.
>
> > ciao
> > oli
> >
>
>
> --
> Bret Busby
> Armadale
> West Australia
> ..............
>
> "So once you do know what the question actually is,
>  you'll know what the answer means."
> - Deep Thought,
>  Chapter 28 of Book 1 of
>  "The Hitchhiker's Guide to the Galaxy:
>  A Trilogy In Four Parts",
>  written by Douglas Adams,
>  published by Pan Books, 1992
>
> ....................................................
>
> --
> ubuntu-users mailing list
> [hidden email]
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

--

mike marchywka
306 charles cox
canton GA 30115
USA, Earth
[hidden email]
404-788-1216
ORCID: 0000-0001-9237-455X

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: Request for explanation of error message

Bret Busby-2
In reply to this post by Bret Busby-2
On 30/07/2019, Bret Busby <[hidden email]> wrote:

> On 30/07/2019, Oliver Grawert <[hidden email]> wrote:
>> hi,
>> Am Montag, den 29.07.2019, 19:57 +0000 schrieb Mike Marchywka:
>>> >
>>> >
>>> > >
>>> > > How often do you get the PCI errors? Do you check dmesg often?
>>> > >
>>> > The PCI errors appear to be ongoing and incessant.
>>> This may be relevant,
>>>
>>> https://askubuntu.com/questions/771899/pcie-bus-error-severity-
>>> corrected
>>
>> well, this points to:
>>
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1521173
>>
>> which has a lot of debug info and potential things to try ...
>>
>
> I was previously referred to an "ask ubuntu" forum web page with a
> question and solutions relating to this, and, I changed the two lines
> in the grub file, to insert
> pci=nomsi
> then, whilst that stopped the growth of x-0.log , it did not stop the
> error repeating in dmesg output, so I replaced the nomsi with noaer,
> as was suggested, but, again, the same; the
> x-0.log file appears to have stopped growing, but, the error message
> is still incessantly repeating in dmesg.
>

Now here's a new observation.

After a while with no substantial increase in the size of the x-0.log
file, I decided to try to restore a Falkon session.

That is after a reboot, with no other web browsers running.

The x-0.log file then started growing again, at a rate of about 110MB
per 30 seconds.

I stopped it (used the "Force a misbehaving application to quit" panel
applet application with the fractured window icon), and the size of
the x-0.log file stopped growing and stayed at about 762MB.

I then restored a session of the bodgy midori browser (it turns a four
window session into 15 windows, and, opens mutiple malicious speed
dial windows, with multiple malicious speed dial tabs in them, in
addition to previous windows, and, adds malicious speed dial tabs into
windows that did not have them), and, loaded konqueror, to access
gmail.

After that, and, closing the superfluous and unwanted speed dial
windows and the superfluous and unwanted speed dial tabs in the
pre-existing windows that were wanted to be restored in midori, the
x-0.log file is still sitting at about 762MB (caja shows its size as
762.6MB), so, opening those two web browsers, did not increase the
size of the x-0.log file.

So, running Falkon appears to result in the x-0.log file eating the
system freespace; maybe, instead of being named Falkon, it should be
named PacMan.

--
Bret Busby
Armadale
West Australia
..............

"So once you do know what the question actually is,
 you'll know what the answer means."
- Deep Thought,
 Chapter 28 of Book 1 of
 "The Hitchhiker's Guide to the Galaxy:
 A Trilogy In Four Parts",
 written by Douglas Adams,
 published by Pan Books, 1992

....................................................

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: Request for explanation of error message

Oliver Grawert
In reply to this post by Bret Busby-2
hi,
Am Dienstag, den 30.07.2019, 06:21 +0800 schrieb Bret Busby:

> On 30/07/2019, Oliver Grawert <[hidden email]> wrote:
> > 
> > well, this points to:
> >
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1521173
> >
> > which has a lot of debug info and potential things to try ...
> >
> I was previously referred to an "ask ubuntu" forum web page with a
> question and solutions relating to this, and, I changed the two lines
> in the grub file, to insert
> pci=nomsi
> then, whilst that stopped the growth of x-0.log , it did not stop the
> error repeating in dmesg output, so I replaced the nomsi with noaer,
> as was suggested, but, again, the same; the
> x-0.log file appears to have stopped growing, but, the error message
> is still incessantly repeating in dmesg.
as i said, there is more in that bug (worth reading it) ... 

start with:

lspci -vt

which should print a tree of your pci devices, so you can potentially
see what's the attached device causing the controller to go wild, it
talks about various BIOS options you can try ... and indeed you could
also try to update your BIOS to a new version of the mainboard
manufacturer ...

ciao
        oli
--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Request for explanation of error message

Bret Busby-2
On 30/07/2019, Oliver Grawert <[hidden email]> wrote:

> hi,
> Am Dienstag, den 30.07.2019, 06:21 +0800 schrieb Bret Busby:
>> On 30/07/2019, Oliver Grawert <[hidden email]> wrote:
>> >
>> > well, this points to:
>> >
>> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1521173
>> >
>> > which has a lot of debug info and potential things to try ...
>> >
>> I was previously referred to an "ask ubuntu" forum web page with a
>> question and solutions relating to this, and, I changed the two lines
>> in the grub file, to insert
>> pci=nomsi
>> then, whilst that stopped the growth of x-0.log , it did not stop the
>> error repeating in dmesg output, so I replaced the nomsi with noaer,
>> as was suggested, but, again, the same; the
>> x-0.log file appears to have stopped growing, but, the error message
>> is still incessantly repeating in dmesg.
>
> as i said, there is more in that bug (worth reading it) ...
>
> start with:
>
> lspci -vt
>
> which should print a tree of your pci devices, so you can potentially
> see what's the attached device causing the controller to go wild,

Thank you for that.

"
bret@bret-MD34045-2521:~$ lspci -vt
-[0000:00]-+-00.0  Intel Corporation 8th Gen Core Processor Host
Bridge/DRAM Registers
           +-02.0  Intel Corporation 8th Gen Core Processor Gaussian
Mixture Model
           +-08.0  Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 /
6th/7th Gen Core Processor Gaussian Mixture Model
           +-14.0  Intel Corporation 200 Series/Z370 Chipset Family
USB 3.0 xHCI Controller
           +-14.2  Intel Corporation 200 Series PCH Thermal Subsystem
           +-15.0  Intel Corporation 200 Series PCH Serial IO I2C Controller #0
           +-15.1  Intel Corporation 200 Series PCH Serial IO I2C Controller #1
           +-16.0  Intel Corporation 200 Series PCH CSME HECI #1
           +-17.0  Intel Corporation SATA Controller [RAID mode]
           +-1c.0-[01]----00.0  Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
           +-1d.0-[02]----00.0  Intel Corporation Wireless 3165
           +-1e.0  Intel Corporation 200 Series/Z370 Chipset Family
Serial IO UART Controller #0
           +-1f.0  Intel Corporation Z370 Chipset LPC/eSPI Controller
           +-1f.2  Intel Corporation 200 Series/Z370 Chipset Family
Power Management Controller
           +-1f.3  Intel Corporation 200 Series PCH HD Audio
           \-1f.4  Intel Corporation 200 Series/Z370 Chipset Family
SMBus Controller
bret@bret-MD34045-2521:~$
"

So, I assume that the fault involves the WiFi thingy.



> it
> talks about various BIOS options you can try ... and indeed you could
> also try to update your BIOS to a new version of the mainboard
> manufacturer ...
>

I have never updated a BIOS on a system.

How do I do that?

> ciao
> oli


--
Bret Busby
Armadale
West Australia
..............

"So once you do know what the question actually is,
 you'll know what the answer means."
- Deep Thought,
 Chapter 28 of Book 1 of
 "The Hitchhiker's Guide to the Galaxy:
 A Trilogy In Four Parts",
 written by Douglas Adams,
 published by Pan Books, 1992

....................................................

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: Request for explanation of error message

Bret Busby-2
On 30/07/2019, Bret Busby <[hidden email]> wrote:

> On 30/07/2019, Oliver Grawert <[hidden email]> wrote:
>> hi,
>> Am Dienstag, den 30.07.2019, 06:21 +0800 schrieb Bret Busby:
>>> On 30/07/2019, Oliver Grawert <[hidden email]> wrote:
>>> >
>>> > well, this points to:
>>> >
>>> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1521173
>>> >
>>> > which has a lot of debug info and potential things to try ...
>>> >
>>> I was previously referred to an "ask ubuntu" forum web page with a
>>> question and solutions relating to this, and, I changed the two lines
>>> in the grub file, to insert
>>> pci=nomsi
>>> then, whilst that stopped the growth of x-0.log , it did not stop the
>>> error repeating in dmesg output, so I replaced the nomsi with noaer,
>>> as was suggested, but, again, the same; the
>>> x-0.log file appears to have stopped growing, but, the error message
>>> is still incessantly repeating in dmesg.
>>
>> as i said, there is more in that bug (worth reading it) ...
>>
>> start with:
>>
>> lspci -vt
>>
>> which should print a tree of your pci devices, so you can potentially
>> see what's the attached device causing the controller to go wild,
>
> Thank you for that.
>
> "
> bret@bret-MD34045-2521:~$ lspci -vt
> -[0000:00]-+-00.0  Intel Corporation 8th Gen Core Processor Host
> Bridge/DRAM Registers
>            +-02.0  Intel Corporation 8th Gen Core Processor Gaussian
> Mixture Model
>            +-08.0  Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 /
> 6th/7th Gen Core Processor Gaussian Mixture Model
>            +-14.0  Intel Corporation 200 Series/Z370 Chipset Family
> USB 3.0 xHCI Controller
>            +-14.2  Intel Corporation 200 Series PCH Thermal Subsystem
>            +-15.0  Intel Corporation 200 Series PCH Serial IO I2C Controller
> #0
>            +-15.1  Intel Corporation 200 Series PCH Serial IO I2C Controller
> #1
>            +-16.0  Intel Corporation 200 Series PCH CSME HECI #1
>            +-17.0  Intel Corporation SATA Controller [RAID mode]
>            +-1c.0-[01]----00.0  Realtek Semiconductor Co., Ltd.
> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
>            +-1d.0-[02]----00.0  Intel Corporation Wireless 3165
>            +-1e.0  Intel Corporation 200 Series/Z370 Chipset Family
> Serial IO UART Controller #0
>            +-1f.0  Intel Corporation Z370 Chipset LPC/eSPI Controller
>            +-1f.2  Intel Corporation 200 Series/Z370 Chipset Family
> Power Management Controller
>            +-1f.3  Intel Corporation 200 Series PCH HD Audio
>            \-1f.4  Intel Corporation 200 Series/Z370 Chipset Family
> SMBus Controller
> bret@bret-MD34045-2521:~$
> "
>
> So, I assume that the fault involves the WiFi thingy.
>
>
>
>> it
>> talks about various BIOS options you can try ... and indeed you could
>> also try to update your BIOS to a new version of the mainboard
>> manufacturer ...
>>
>
> I have never updated a BIOS on a system.
>
> How do I do that?
>


Now - an update.

1. On the premise that the error relates to the WiFi adaptor (?), as
my wife has used USB tethering to access the WWW via her cellphone,
using the 4G network, as that operates almost as a plug and play thing
(USB tethering needs to be enabled on the cellpnone, after the
cellphone is connected via USB, to the computer), I thought I would
try that, and, disconnect the WiFi connection.

So, after doing that, and, running a speedtest (ozspeedtest.com),
apart from dmesg returning some errors from the web browser (midori),
after 20 minutes of the USB tethering connection and running dmesg,
dmesg shows no new errors, for the 20 minute period.

2. A previous suggestion was made to check the new RAM, via the system
BIOS, if possible. I have checked, and, whilst synaptic shows
memtest86+ to be installed, it does not show as an option in the GRUB
menu, and, no option is apparent, from the system BIOS, for testing
the RAM. I have not been able to find a way to manually invoke
memtest86+.

3. I contacted Medion Australia, to find whether any BIOS upgrades are
available for the computer, and, their response was that the only
downloadable drivers for the computer, that they have, are at
https://www.medion.com/gb/service/_lightbox/treiber.php?msn=10022163&prod=MEDION
AKOYA P40000 (MD 34045) AU
which, from what I perceive, shows that only downloadable drivers for
MS Windows 10, are available from Medion, the computer manufacturer.

So, until I can find a fix for the WiFi adaptor (?) problem, which
appears to be the device of the problem, USB tethering appears to be
the way around it - it is apparently not as fast as WiFi, but, it is
usable, withou apparent errors. When I can, I will take the computer
back to the computer shop that installed the RAM, to get the integrity
 of the fit of the WiFi adaptor, checked, in case, as suggested as a
possibility, it is partially dislodged (it still works, enabling WiFi
access, but, it apparently has the errors).

And, in the last 15 minutes, of writing this message, the only new
error whown by dmesg, relates to midori.

x-0.log stil shows as 762.6MB.


--
Bret Busby
Armadale
West Australia
..............

"So once you do know what the question actually is,
 you'll know what the answer means."
- Deep Thought,
 Chapter 28 of Book 1 of
 "The Hitchhiker's Guide to the Galaxy:
 A Trilogy In Four Parts",
 written by Douglas Adams,
 published by Pan Books, 1992

....................................................

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: Request for explanation of error message

Liam Proven
On Tue, 30 Jul 2019 at 16:12, Bret Busby <[hidden email]> wrote:

> I have not been able to find a way to manually invoke
> memtest86+.

Boot from any Ubuntu install medium. It's on the boot menu. DVD, CD,
USB, doesn't matter. Does not affect the installed system in any way.

--
Liam Proven - Profile: https://about.me/liamproven
Email: [hidden email] - Google Mail/Hangouts/Plus: [hidden email]
Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven
UK: +44 7939-087884 - ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: Request for explanation of error message

Rashkae-2
On 2019-07-30 10:52 a.m., Liam Proven wrote:
> On Tue, 30 Jul 2019 at 16:12, Bret Busby <[hidden email]> wrote:
>
>> I have not been able to find a way to manually invoke
>> memtest86+.
>
> Boot from any Ubuntu install medium. It's on the boot menu. DVD, CD,
> USB, doesn't matter. Does not affect the installed system in any way.
>


If your computer is UEFI, you have to enable Legacy Boot, either as an
on-the fly boot option, or maybe in your BIOS.

The open Source Memtest86+ can not be run from an EFI Boot and is not
presented as an option.



--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: Request for explanation of error message

Bret Busby-2
On 30/07/2019, Rashkae <[hidden email]> wrote:

> On 2019-07-30 10:52 a.m., Liam Proven wrote:
>> On Tue, 30 Jul 2019 at 16:12, Bret Busby <[hidden email]> wrote:
>>
>>> I have not been able to find a way to manually invoke
>>> memtest86+.
>>
>> Boot from any Ubuntu install medium. It's on the boot menu. DVD, CD,
>> USB, doesn't matter. Does not affect the installed system in any way.
>>
>
>
> If your computer is UEFI, you have to enable Legacy Boot, either as an
> on-the fly boot option, or maybe in your BIOS.
>
> The open Source Memtest86+ can not be run from an EFI Boot and is not
> presented as an option.
>
>

Ah.

It is UEFI.

With that and it having MS Win10 preinstalled, that is why I installed
UbuntuMATE 18.04 (now 18.04.2), rather than 16.04.

It does not matter so much - the RAM appears to be working fine.

--
Bret Busby
Armadale
West Australia
..............

"So once you do know what the question actually is,
 you'll know what the answer means."
- Deep Thought,
 Chapter 28 of Book 1 of
 "The Hitchhiker's Guide to the Galaxy:
 A Trilogy In Four Parts",
 written by Douglas Adams,
 published by Pan Books, 1992

....................................................

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: Request for explanation of error message

Mike Marchywka
In reply to this post by Bret Busby-2

So just to clarify, lightdm began functioning without flooding the log files
when you switched wifi connections presumably due to a ( correctable )
error from the WiFi PCI card? And this started after you had a memory upgated.

________________________________________
From: ubuntu-users <[hidden email]> on behalf of Bret Busby <[hidden email]>
Sent: Tuesday, July 30, 2019 10:09 AM
To: Ubuntu user technical support, not for general discussions
Subject: Re: Request for explanation of error message

On 30/07/2019, Bret Busby <[hidden email]> wrote:

> On 30/07/2019, Oliver Grawert <[hidden email]> wrote:
>> hi,
>> Am Dienstag, den 30.07.2019, 06:21 +0800 schrieb Bret Busby:
>>> On 30/07/2019, Oliver Grawert <[hidden email]> wrote:
>>> >
>>> > well, this points to:
>>> >
>>> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1521173
>>> >
>>> > which has a lot of debug info and potential things to try ...
>>> >
>>> I was previously referred to an "ask ubuntu" forum web page with a
>>> question and solutions relating to this, and, I changed the two lines
>>> in the grub file, to insert
>>> pci=nomsi
>>> then, whilst that stopped the growth of x-0.log , it did not stop the
>>> error repeating in dmesg output, so I replaced the nomsi with noaer,
>>> as was suggested, but, again, the same; the
>>> x-0.log file appears to have stopped growing, but, the error message
>>> is still incessantly repeating in dmesg.
>>
>> as i said, there is more in that bug (worth reading it) ...
>>
>> start with:
>>
>> lspci -vt
>>
>> which should print a tree of your pci devices, so you can potentially
>> see what's the attached device causing the controller to go wild,
>
> Thank you for that.
>
> "
> bret@bret-MD34045-2521:~$ lspci -vt
> -[0000:00]-+-00.0  Intel Corporation 8th Gen Core Processor Host
> Bridge/DRAM Registers
>            +-02.0  Intel Corporation 8th Gen Core Processor Gaussian
> Mixture Model
>            +-08.0  Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 /
> 6th/7th Gen Core Processor Gaussian Mixture Model
>            +-14.0  Intel Corporation 200 Series/Z370 Chipset Family
> USB 3.0 xHCI Controller
>            +-14.2  Intel Corporation 200 Series PCH Thermal Subsystem
>            +-15.0  Intel Corporation 200 Series PCH Serial IO I2C Controller
> #0
>            +-15.1  Intel Corporation 200 Series PCH Serial IO I2C Controller
> #1
>            +-16.0  Intel Corporation 200 Series PCH CSME HECI #1
>            +-17.0  Intel Corporation SATA Controller [RAID mode]
>            +-1c.0-[01]----00.0  Realtek Semiconductor Co., Ltd.
> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
>            +-1d.0-[02]----00.0  Intel Corporation Wireless 3165
>            +-1e.0  Intel Corporation 200 Series/Z370 Chipset Family
> Serial IO UART Controller #0
>            +-1f.0  Intel Corporation Z370 Chipset LPC/eSPI Controller
>            +-1f.2  Intel Corporation 200 Series/Z370 Chipset Family
> Power Management Controller
>            +-1f.3  Intel Corporation 200 Series PCH HD Audio
>            \-1f.4  Intel Corporation 200 Series/Z370 Chipset Family
> SMBus Controller
> bret@bret-MD34045-2521:~$
> "
>
> So, I assume that the fault involves the WiFi thingy.
>
>
>
>> it
>> talks about various BIOS options you can try ... and indeed you could
>> also try to update your BIOS to a new version of the mainboard
>> manufacturer ...
>>
>
> I have never updated a BIOS on a system.
>
> How do I do that?
>


Now - an update.

1. On the premise that the error relates to the WiFi adaptor (?), as
my wife has used USB tethering to access the WWW via her cellphone,
using the 4G network, as that operates almost as a plug and play thing
(USB tethering needs to be enabled on the cellpnone, after the
cellphone is connected via USB, to the computer), I thought I would
try that, and, disconnect the WiFi connection.

So, after doing that, and, running a speedtest (ozspeedtest.com),
apart from dmesg returning some errors from the web browser (midori),
after 20 minutes of the USB tethering connection and running dmesg,
dmesg shows no new errors, for the 20 minute period.

2. A previous suggestion was made to check the new RAM, via the system
BIOS, if possible. I have checked, and, whilst synaptic shows
memtest86+ to be installed, it does not show as an option in the GRUB
menu, and, no option is apparent, from the system BIOS, for testing
the RAM. I have not been able to find a way to manually invoke
memtest86+.

3. I contacted Medion Australia, to find whether any BIOS upgrades are
available for the computer, and, their response was that the only
downloadable drivers for the computer, that they have, are at
https://www.medion.com/gb/service/_lightbox/treiber.php?msn=10022163&prod=MEDION
AKOYA P40000 (MD 34045) AU
which, from what I perceive, shows that only downloadable drivers for
MS Windows 10, are available from Medion, the computer manufacturer.

So, until I can find a fix for the WiFi adaptor (?) problem, which
appears to be the device of the problem, USB tethering appears to be
the way around it - it is apparently not as fast as WiFi, but, it is
usable, withou apparent errors. When I can, I will take the computer
back to the computer shop that installed the RAM, to get the integrity
 of the fit of the WiFi adaptor, checked, in case, as suggested as a
possibility, it is partially dislodged (it still works, enabling WiFi
access, but, it apparently has the errors).

And, in the last 15 minutes, of writing this message, the only new
error whown by dmesg, relates to midori.

x-0.log stil shows as 762.6MB.


--
Bret Busby
Armadale
West Australia
..............

"So once you do know what the question actually is,
 you'll know what the answer means."
- Deep Thought,
 Chapter 28 of Book 1 of
 "The Hitchhiker's Guide to the Galaxy:
 A Trilogy In Four Parts",
 written by Douglas Adams,
 published by Pan Books, 1992

....................................................

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: Request for explanation of error message

Bret Busby-2
On 30/07/2019, Mike Marchywka <[hidden email]> wrote:

>
> So just to clarify, lightdm began functioning without flooding the log files
> when you switched wifi connections presumably due to a ( correctable )
> error from the WiFi PCI card? And this started after you had a memory
> upgated.
>
> ________________________________________
> From: ubuntu-users <[hidden email]> on behalf of Bret
> Busby <[hidden email]>
> Sent: Tuesday, July 30, 2019 10:09 AM
> To: Ubuntu user technical support, not for general discussions
> Subject: Re: Request for explanation of error message
>
> On 30/07/2019, Bret Busby <[hidden email]> wrote:
>> On 30/07/2019, Oliver Grawert <[hidden email]> wrote:
>>> hi,
>>> Am Dienstag, den 30.07.2019, 06:21 +0800 schrieb Bret Busby:
>>>> On 30/07/2019, Oliver Grawert <[hidden email]> wrote:
>>>> >
>>>> > well, this points to:
>>>> >
>>>> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1521173
>>>> >
>>>> > which has a lot of debug info and potential things to try ...
>>>> >
>>>> I was previously referred to an "ask ubuntu" forum web page with a
>>>> question and solutions relating to this, and, I changed the two lines
>>>> in the grub file, to insert
>>>> pci=nomsi
>>>> then, whilst that stopped the growth of x-0.log , it did not stop the
>>>> error repeating in dmesg output, so I replaced the nomsi with noaer,
>>>> as was suggested, but, again, the same; the
>>>> x-0.log file appears to have stopped growing, but, the error message
>>>> is still incessantly repeating in dmesg.
>>>
>>> as i said, there is more in that bug (worth reading it) ...
>>>
>>> start with:
>>>
>>> lspci -vt
>>>
>>> which should print a tree of your pci devices, so you can potentially
>>> see what's the attached device causing the controller to go wild,
>>
>> Thank you for that.
>>
>> "
>> bret@bret-MD34045-2521:~$ lspci -vt
>> -[0000:00]-+-00.0  Intel Corporation 8th Gen Core Processor Host
>> Bridge/DRAM Registers
>>            +-02.0  Intel Corporation 8th Gen Core Processor Gaussian
>> Mixture Model
>>            +-08.0  Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 /
>> 6th/7th Gen Core Processor Gaussian Mixture Model
>>            +-14.0  Intel Corporation 200 Series/Z370 Chipset Family
>> USB 3.0 xHCI Controller
>>            +-14.2  Intel Corporation 200 Series PCH Thermal Subsystem
>>            +-15.0  Intel Corporation 200 Series PCH Serial IO I2C
>> Controller
>> #0
>>            +-15.1  Intel Corporation 200 Series PCH Serial IO I2C
>> Controller
>> #1
>>            +-16.0  Intel Corporation 200 Series PCH CSME HECI #1
>>            +-17.0  Intel Corporation SATA Controller [RAID mode]
>>            +-1c.0-[01]----00.0  Realtek Semiconductor Co., Ltd.
>> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
>>            +-1d.0-[02]----00.0  Intel Corporation Wireless 3165
>>            +-1e.0  Intel Corporation 200 Series/Z370 Chipset Family
>> Serial IO UART Controller #0
>>            +-1f.0  Intel Corporation Z370 Chipset LPC/eSPI Controller
>>            +-1f.2  Intel Corporation 200 Series/Z370 Chipset Family
>> Power Management Controller
>>            +-1f.3  Intel Corporation 200 Series PCH HD Audio
>>            \-1f.4  Intel Corporation 200 Series/Z370 Chipset Family
>> SMBus Controller
>> bret@bret-MD34045-2521:~$
>> "
>>
>> So, I assume that the fault involves the WiFi thingy.
>>
>>
>>
>>> it
>>> talks about various BIOS options you can try ... and indeed you could
>>> also try to update your BIOS to a new version of the mainboard
>>> manufacturer ...
>>>
>>
>> I have never updated a BIOS on a system.
>>
>> How do I do that?
>>
>
>
> Now - an update.
>
> 1. On the premise that the error relates to the WiFi adaptor (?), as
> my wife has used USB tethering to access the WWW via her cellphone,
> using the 4G network, as that operates almost as a plug and play thing
> (USB tethering needs to be enabled on the cellpnone, after the
> cellphone is connected via USB, to the computer), I thought I would
> try that, and, disconnect the WiFi connection.
>
> So, after doing that, and, running a speedtest (ozspeedtest.com),
> apart from dmesg returning some errors from the web browser (midori),
> after 20 minutes of the USB tethering connection and running dmesg,
> dmesg shows no new errors, for the 20 minute period.
>
> 2. A previous suggestion was made to check the new RAM, via the system
> BIOS, if possible. I have checked, and, whilst synaptic shows
> memtest86+ to be installed, it does not show as an option in the GRUB
> menu, and, no option is apparent, from the system BIOS, for testing
> the RAM. I have not been able to find a way to manually invoke
> memtest86+.
>
> 3. I contacted Medion Australia, to find whether any BIOS upgrades are
> available for the computer, and, their response was that the only
> downloadable drivers for the computer, that they have, are at
> https://www.medion.com/gb/service/_lightbox/treiber.php?msn=10022163&prod=MEDION
> AKOYA P40000 (MD 34045) AU
> which, from what I perceive, shows that only downloadable drivers for
> MS Windows 10, are available from Medion, the computer manufacturer.
>
> So, until I can find a fix for the WiFi adaptor (?) problem, which
> appears to be the device of the problem, USB tethering appears to be
> the way around it - it is apparently not as fast as WiFi, but, it is
> usable, withou apparent errors. When I can, I will take the computer
> back to the computer shop that installed the RAM, to get the integrity
>  of the fit of the WiFi adaptor, checked, in case, as suggested as a
> possibility, it is partially dislodged (it still works, enabling WiFi
> access, but, it apparently has the errors).
>
> And, in the last 15 minutes, of writing this message, the only new
> error whown by dmesg, relates to midori.
>
> x-0.log stil shows as 762.6MB.
>


The flooding of the log files, stopped, when I inserted the
"pci=nomsi"
in the grub file;

"
I was previously referred to an "ask ubuntu" forum web page with a
question and solutions relating to this, and, I changed the two lines
in the grub file, to insert
pci=nomsi
then, whilst that stopped the growth of x-0.log , it did not stop the
error repeating in dmesg output, so I replaced the nomsi with noaer,
as was suggested, but, again, the same; the
x-0.log file appears to have stopped growing, but, the error message
is still incessantly repeating in dmesg.
"

and, the error included in the dmesg output, stopped freshly appearing
when I stopped using the WiFi and switched to the USB tethering, as
stated above.

--
Bret Busby
Armadale
West Australia
..............

"So once you do know what the question actually is,
 you'll know what the answer means."
- Deep Thought,
 Chapter 28 of Book 1 of
 "The Hitchhiker's Guide to the Galaxy:
 A Trilogy In Four Parts",
 written by Douglas Adams,
 published by Pan Books, 1992

....................................................

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: Request for explanation of error message

Rashkae-2
In reply to this post by Bret Busby-2
On 2019-07-30 11:19 a.m., Bret Busby wrote:

>
> Ah.
>
> It is UEFI.
>
> With that and it having MS Win10 preinstalled, that is why I installed
> UbuntuMATE 18.04 (now 18.04.2), rather than 16.04.

You can download the somewhat proprietary Memtest86 from here:

https://www.memtest86.com/

It's not open source, but it's no charge, very functional, and
development has outrun the open source version by an embarrassing margin.



--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
1234