Need help troubleshooting NIC (ethernet card) on Manjaro KDE

Hii, I have posted previously regarding this issue…
From previous forum post, suggestion is NIC dead… But now i used manjaro live cd boot up, The network card is fine… i can access this forum with it.

Anyway to fix it without reinstalling ?
1st question:
Since for linux , all drivers were “built in” into Kernel…
And since ethernet card driver is not working…
Cant i just download a new kernel or just reinstall the very same kernel … will that fix the problem ?

  $ sudo inxi --full --admin --verbosity=7 --filter --no-host
System:
  Kernel: 5.10.36-2-MANJARO x86_64 bits: 64 compiler: gcc v: 10.2.0 
  parameters: BOOT_IMAGE=/boot/vmlinuz-x86_64 lang=en_US keytable=us 
  tz=UTC misobasedir=manjaro misolabel=MANJARO_KDE_2105 quiet 
  systemd.show_status=1 apparmor=1 security=apparmor driver=nonfree 
  nouveau.modeset=0 i915.modeset=1 radeon.modeset=1 
  Console: tty pts/2 wm: kwin_x11 DM: SDDM Distro: Manjaro Linux 
  base: Arch Linux 
Machine:
  Type: Desktop System: Dell product: OptiPlex 755 v: N/A 
  serial: <filter> Chassis: type: 6 serial: <filter> 
  Mobo: Dell model: 0GM819 serial: <filter> BIOS: Dell v: A19 
  date: 05/31/2011 
Network:
  Device-1: Intel 82557/8/9/0/1 Ethernet Pro 100 driver: e100 v: kernel 
  port: dcc0 bus-ID: 03:00.0 chip-ID: 8086:1229 class-ID: 0200 
  IF: enp3s0 state: up speed: 100 Mbps duplex: full mac: <filter> 
  IP v4: <filter> type: dynamic noprefixroute scope: global 
  broadcast: <filter> 
  IP v6: <filter> type: dynamic noprefixroute scope: global 
  IP v6: <filter> type: noprefixroute scope: link 
  WAN IP: <filter> 
USB:
  Hub-1: 1-0:1 info: Full speed (or root) Hub ports: 6 rev: 2.0 
  speed: 480 Mb/s chip-ID: 1d6b:0002 class-ID: 0900 
  Device-1: 1-1:2 info: SanDisk Cruzer Blade type: Mass Storage 
  driver: usb-storage interfaces: 1 rev: 2.1 speed: 480 Mb/s 
  power: 224mA chip-ID: 0781:5567 class-ID: 0806 serial: <filter> 
  Hub-2: 2-0:1 info: Full speed (or root) Hub ports: 6 rev: 2.0 
  speed: 480 Mb/s chip-ID: 1d6b:0002 class-ID: 0900 
  Hub-3: 3-0:1 info: Full speed (or root) Hub ports: 2 rev: 1.1 
  speed: 12 Mb/s chip-ID: 1d6b:0001 class-ID: 0900 
  Hub-4: 4-0:1 info: Full speed (or root) Hub ports: 2 rev: 1.1 
  speed: 12 Mb/s chip-ID: 1d6b:0001 class-ID: 0900 
  Device-1: 4-1:2 info: Pixart Imaging Optical Mouse type: Mouse 
  driver: hid-generic,usbhid interfaces: 1 rev: 2.0 speed: 1.5 Mb/s 
  power: 100mA chip-ID: 093a:2510 class-ID: 0301 
  Device-2: 4-2:3 info: Chicony USB Keyboard type: Keyboard,HID 
  driver: hid-generic,usbhid interfaces: 2 rev: 2.0 speed: 1.5 Mb/s 
  power: 100mA chip-ID: 04f2:1516 class-ID: 0300 
  Hub-5: 5-0:1 info: Full speed (or root) Hub ports: 2 rev: 1.1 
  speed: 12 Mb/s chip-ID: 1d6b:0001 class-ID: 0900 
  Hub-6: 6-0:1 info: Full speed (or root) Hub ports: 2 rev: 1.1 
  speed: 12 Mb/s chip-ID: 1d6b:0001 class-ID: 0900 
  Hub-7: 7-0:1 info: Full speed (or root) Hub ports: 2 rev: 1.1 
  speed: 12 Mb/s chip-ID: 1d6b:0001 class-ID: 0900 
Info:
  Processes: 160 Uptime: 47m wakeups: 0 Init: systemd v: 247 
  tool: systemctl Compilers: gcc: N/A Packages: pacman: 1219 lib: 326 
  flatpak: 0 Shell: Bash (sudo) v: 5.1.8 running-in: konsole 
  inxi: 3.3.04


    $ lspci
00:00.0 Host bridge: Intel Corporation 82Q35 Express DRAM Controller (rev 02)
00:01.0 PCI bridge: Intel Corporation 82Q35 Express PCI Express Root Port (rev 02)
00:02.0 VGA compatible controller: Intel Corporation 82Q35 Express Integrated Graphics Controller (rev 02)
00:02.1 Display controller: Intel Corporation 82Q35 Express Integrated Graphics Controller (rev 02)
00:1a.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 02)
00:1a.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 02)
00:1a.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 02)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 02)
00:1d.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 02)
00:1d.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92)
00:1f.0 ISA bridge: Intel Corporation 82801IO (ICH9DO) LPC Interface Controller (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 4 port SATA Controller [IDE mode] (rev 02)
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02)
00:1f.5 IDE interface: Intel Corporation 82801I (ICH9 Family) 2 port SATA Controller [IDE mode] (rev 02)
03:00.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 08)

Hello there

Can you try kernel 5.13?

No, this will not work. The module (driver) is compiled against the current version. It have no effect on other kernels. So, if kernel 5.10 works for you, why do you really want to upgrade the kernel? LTS is quite safe to use without upgrading it every 3 months with stable one.

However… when i read you previous post, then i assume that the module e100 does not “de-freeze” correctly after wakeup. Only the logs can say more…

Can you please explain what do you meant by "the driver module is compiled AGAINST the current version (which is Kernel: 5.10.36-2-MANJARO gcc v: 10.2.0 ) ? My english is not that good. Did you meant the “driver module is compiled FOR current version of kernel - 5.10.36-2 Manjaro” ?
If anybody install a newer kernel , will the so called “driver module” not be also recompiled too ? else how can it possible for anybody to run a newer kernel without crashing ?

No really my liking to upgrade kernel from LTS to Non-LTS, was just asking.
Since the modules are compiled for kernel 5.10, can i just reinstall kernel 5.10… will that fix the problem ?

What is module e100 ? Where did you see it ? Can please explain ?

Which log can provide more info, can you show me the cli command to me ? Thanks
I have restarted the desktop already, does the log still hav the info that relevant ?

That does mean: it uses the header files of the current kernel and can only be used with this kernel.

This driver (e100) comes precompiled. But there also DKMS ( Dynamic Kernel Module Support) which compiles the driver module when the kernel has been upgraded, changed a new one has been installed.

If there no problem with v5.10, then don’t change it. Only if you have a good reason. I assume the problem happens only when suspending, so there must be something wrong with the driver or the firmware (UEFI/BIOS), since it interacts there through ACPI.

Here:

modinfo e100

will display more information and also parameters on the bottom.

Sure… for example:

Show only messages of the NetworkManager Service:

journalctl --since=today --unit=NetworkManager --no-pager

OR

Show diagnostic messages and filter out the module:

journalctl --dmesg --grep="e100" --no-pager

OR

Show all errors of this day:

journalctl --priority=err --no-pager --since=today

I was trying to access manjaro forum after woke up the desktop from suspend into ram… somehow…
inxi --verbosity=7
and
ip addr
causes konsole to not able to execute the command above (it is not freeze, but not producing any output)… weird… is it really suspend and wake up causing problem ? ? this is Live iso… so weird… ! Need to reboot again…

try to suspend with:

systemctl suspend

and please report back if the problem is the same.

And yes ACPI does not work correctly with Linux it seems.

Yap, you are right, after i execute systemctl suspend into ram, the NIC failed… and inxi --verbosity=7 again doesn’t produce output… but it is not freeze.
Something Not right… kernel fault ? But my manjaro live iso is running 5.10.36-2 kernel (uname -r)… it suppose to be stable kernel…
Now, i executed shutdown now : it took over 5 minutes to shutdown… avahi and user manager, (something like A stop job is running for user manager (4 mins / 5mins) then it took another ~7 mins to shutdown network manager…

I have boot up my desktop (the one with NIC failure), the network card is fine… working. i checked the kernel that is running right now, uname -r it is kernel 5.4.131.1

Commonly linux follows strictly ACPI specifications. Some UEFI/BIOS have exceptions or workarounds for Windows, but not Linux. Maybe your UEFI is just buggy… Can’t say anything specific here…

Please upload your full log from today of your local installation:

journalctl --since=today  | curl -F'file=@-' https://0x0.st

That uploads the full log and print a URL on the terminal. It should contain what happened during suspend.

Err… How on earth can i post Journal logging to you? … now that the os on the desktop itself no longer have the NIC issue when “suspend to ram” ? I hate this kind of issue…
I just tried 2 times of suspend, but everytime it wakes up without NIC problem… appears to be “fixed itself ?” I hate this kind of thing… unknown problem fixed unknowingly… and reoccurs again in future…

Maybe fastboot is the problem?

Turn it off… Especially on dual boots it can produce problems…

Maybe change this mode and see if there less problems?

Source: https://downloads.dell.com/manuals/all-products/esuprt_desktop/esuprt_optiplex_desktop/optiplex-755_user's%20guide_en-us.pdf

However… i guess if suspend (S3) also called “deep sleep”, works and it have problems when wake up, then i assume the problem is “fastboot” which I mentioned.

As i wrote:

journalctl --since=today --no-pager

will display all logs of the last 24h.

AND in addition:

curl -F'file=@-' https://0x0.st

it will upload it to https://0x0.st.

The pipe | just stream the output of journalctl to curl, which uploads it.

The - between @ and ' represents the text, which comes from journalctl:

             That
              |
curl -F'file=@-' https://0x0.st

Sorry Megavolt, there is a misunderstanding here.
I understand the journalctl and curl command that you gave me above just fine.
What i meant from my last post was:

I have being using 2 method to boot in the desktop.

  1. desktop own installed kernel 5.4
  2. manjaro live usb with kernel 5.10.
    I first encountered the problem on kernel 5.4.
    Later i tried using usb live image [kernel 5.10] and encounter the exact same problem. (it is from here you started to give me advice on journalctl log). But i was thinking i need to run the desktop own installed kernel in order to provide a useful log to you instead of provide you with the live usb kernel log.

Hence i reboot the desktop with it own kernel (5.4) and behold, the problem has disappeared.
Since no NIC issue now, the journalctl log will no longer provide you with useful data to analyze.
Can i make the journalctl log a bit older log that might have the issue logged ?

And i hate it when i have put in so much time asking around help to solve a repeating issue, but then the problem suddenly subsided… and i can’t proceed to find the root of the problem… And i know the same problem might pop out again sometime in the future… That’s what i hate most… time wasted.

Do you think the journalctl log might still having the problematic log in it , since it has being rebooted so many time ? and over ++ 24 hrs… ? can you reshape the journalctl log command ?

Or can i somehow make my computer accessable to you in order to look inside easier ? I am happy to learn how to do remote login on linux without resolving to 3rd party software such teamviewer (so far have no chance to learn). There is not much important or sensitive data on this desktop anyway… it is just for some non sensitive stuff , like surfing…

BTW, i was thinking of providing you with 2 journalctl log, (1 is before suspend, and 1 is after suspend) to compare with. but then after i suspended the pc and wake up, the NIC still running fine… Hence i don’t know what to do to provide you with a meaningful journalctl log.

I am waiting (not doing anymore reboot to desktop) while waiting for your further advice in order not to make the log even more complicating .

This will filter the suspending message on all boot logs:

journalctl --grep="Starting Suspend\.\.\." --no-pager 

Then you can see which date and time it is and choose the correct boot log.

journalctl --list-boots

Here you will see all logged boots. At the end there is the date and the number at the beginning. Choose the correct date and time and then:

journalctl --boot=-10 --no-pager

for example.

Since suspending is not a new boot, it will be in the same boot log.

1 Like

There is no real temporary solution, but gnome has for example this option:

It creates a vnc server, which is accessible by your ip address and Port 5900. The TCP Port must be open on your NAT in order to have access over internet, since there is no server out there which tunnel your traffic or expose your IP, so it is a real direct connection. It is also possible to set a temporary password here.

But no idea if there is something on KDE like that :man_shrugging: Since I don’t use it.

VNC can be installed and configured also manually.

Most people use a SSH tunnel for extra security. So that VNC runs only locally and can be accessed only locally.

Over SSH one creates a tunnel and forward the port 5900 to the local machine to the remote one over a socks proxy. But here the Port 22 (or a custom one), must be open also.

I have got the " boot log" according to your instruction above,… the log is such a long list… How can i replace out the possible of sensitive data from it. ? like ip or something.

I have also tested $sudo nmcli connection reload" and some other “nmcli” command to restart the network device… There is one time, when i do a restart of Network device; the internet connection become good. but then after a few minutes… the network card disconnected again (same old issue is back)… restart using nmcli command won’t solve it…

so, it is not really issue with suspend… there is something going wrong behind constantly… which log can see what is the whole system doing behind ? things like API calls in windows os… etc…

I will provide boot log and suspend log here after filter out sensitive data… just for safe sake… it is open forum. Even so , i think it should do much harm for all those log data to be expose to public…