issue with netcard of dock gen2 of lenovo l390

[george1421]

@JJ-Fullmer said in issue with netcard of dock gen2 of lenovo l390:

Any reason you didn’t want to try compiling kernel version 5.1.16

Well there are a few reasons.

1. The 5.1.16 kernel is radically different than 4.19.65 and it hasn’t been fully tested with fog and imaging. It was created to see if an updated kernel would address a slow nvme imaging issue that impacts a specific nvme drive. It didn’t resolve the issue by the way.
2. FOG 1.5.7 (the latest GA release) ships with 4.19.64, I wanted to build one off kernels using the kernel version closest to 1.5.7 release so if we have a difference in operation we could tell if it was the one off kernel or something within FOG.
3. The config file on the fogproject github site is configured for FOG 4.19.64 it would probably work on the 5.x.x series, but sometimes the linux folks restructure the kernel and retire some options and bring on new options requiring different parameters.

The intent of me building these one off kernels is to test new ideas and see if certain hardware need specific changes. Its possible based on testing these changes can be integrated into the FOG main line kernel. If I go off willy-nilly on my own using random bits it would be impossible for the developers to reintegrate these changes back into the main line kernel.

I know it was a long answer to a simple question, but the intent is with a specific purpose.

[JJ Fullmer]

@george1421 So I made the new one the default kernel and am Re-imaging the same surfacego that worked this morning and found something odd.
For reference when I imaged it with the same image before it took 3 minutes (according to the image history).

This is where it is at now…

The speed has progressively dropped and is still dropping a little at a time. It’s been running for nearly an hour. It’s using the same storagenode and all that. Only difference is the kernel. Sadly I’m not actually 100% sure which kernel I used that was successful. Pretty sure it was the fog 1.5.7 shipped kernel though. I should really give them better names and take extra notes when testing kernels, so easy to mix them up. At any rate though, this is not a normal behavior.

also, side note that I just noticed, it is frozen in the gui task progress bar at 65% which I assume is when it must have started to crazy slowdown, I had optimistically left it to run.

edit : We discovered a network issue that may have caused the computer to lose its dhcp address and or connection during imaging (rouge dhcp server), will test again when that’s worked out.

[JJ Fullmer]

@george1421 I re-imaged the device with the original fog 1.5.7 kernel and it worked as normal again. So Although I can boot into fog on the new kernel, imaging freezes. It is not impossible that it was a network problem though, so the next surface I test, I’ll use the new kernel and a different switch.

[JJ Fullmer]

@jps Have you had a chance to try the kernel @george1421 made?

[jps]

Hello,
OK that works. Thank you.

[JJ Fullmer]

Another fun side note for anyone interested that also has both the microsoft usb-c adapter for the surface devices and the lenovo usb-c type adapters for lenovos. I know that the microsoft adapter will Not pxe boot the lenovo. However I just discovered that the lenovo usb-c adapter will pxe boot the microsoft surface go. So if there is a problem with the kernel and the microsoft adapter, you could just use the lenovo adapter instead. Or theoretically a device with the same realtek ids mentioned earlier on.

[JJ Fullmer]

@george1421
Did another test of the surface go with the surface usb-c adapter on the new kernel.
It did technically finish the image but at the very end of imaging this db error stuff happened

The image got to 100% complete and thus far everything looks like it’s working, the only thing I can see thus far that didn’t work was writing the image history to the host. Could be unrelated to the kernel and such but this didn’t happen on the other 2 surfaces I imaged today with the lenovo usb-c adapter and a usb 2.0 ethernet adapter.

[Sebastian Roth]

@JJ-Fullmer Do you still see the task in the web UI? It sounds like someone canceled the task at some point after the Surface started to deploy.

[JJ Fullmer]

@Sebastian-Roth While not impossible, that is very unlikely. We have only 2 people with access to do that and we were both watching this happen.
It did go away in the webui though, so perhaps something caused it to cancel.

[Sebastian Roth]

@JJ-Fullmer Are you able to reproduce that very issue again and again?

[JJ Fullmer]

@Sebastian-Roth Sadly I am out of surface go’s to test at this time. Gotta get the ones we have in production.