issue with netcard of dock gen2 of lenovo l390

[JJ Fullmer]

@george1421 Let the fun begin then, I have 4 of these that I need to setup today.

the hardware ID in windows is USB\VID_045E&PID_0927&REV_3100
I’ll get the linux bit shortly

[george1421]

@JJ-Fullmer Ah I see: https://forums.fogproject.org/topic/10943/surface-pro-4-registration-issues/25

045E:0927 == realtek r8152. There are new fingerprints all over that driver. Let me see

[JJ Fullmer]

@george1421 I believe that is a different dongle, the one I have is model 1860, that post references 1821 and 1663, but it’s a fair guess that it’s the same or similar driver. I’m troubleshooting a different problem on one at the moment, but will have it boot into a debug fog session and run lsusb on it on my next reboot.

[george1421]

@JJ-Fullmer Ok well I added it because it wasn’t in the updated driver from realtek. As long as the hardware chip IDs are the same it should work no matter what model the dongle is.

https://drive.google.com/open?id=1RBLVzsFmXfTrn1sG0GE18usD-QOBs7Y6

File name is bzImageRT2

[JJ Fullmer]

@george1421 I was able to boot into a debug session on the surface go with this new kernel.
I don’t have the lenovo l390 to test on at the moment but should be able to test it today. I’ll test it on my lenovo x390 too, but gotta make sure they all work.

Here is the lsusb of the surface go usb-c ethernet adapter

lsusb
Bus 002 Device 002: ID 045e:0955
Bus 001 Device 020: ID 045e:096f
Bus 001 Device 001: ID 1d6b:0002
Bus 001 Device 003: ID 0cf3:e302
Bus 001 Device 002: ID 045e:0957
Bus 002 Device 003: ID 045e:0927
Bus 002 Device 001: ID 1d6b:0003

[JJ Fullmer]

@george1421 I was able to nab an L390 I put into production before the user got here and do a quick test with the adapter on this new kernel. Great success it worked! So this kernel appears to be working on both the usb-c ethernet adapters I have that are manufacturer specific Microsoft and Lenovo.

Which thing did you change then?

[george1421]

@JJ-Fullmer I just added the microsoft hardware ID to the downloaded realtek driver per Sebastian’s request in the linked thread. No other changes were made.

[JJ Fullmer]

@george1421 So this one is good to be tested as the default kernel now?

[george1421]

@JJ-Fullmer Yes until the next thing goes wrong.

That wasn’t meant to sound bad. Its all part of kernel development. As new hardware comes out the drivers need to be updated to accommodate the new hardware IDs, even if the new device is exactly the same as the old devices.

So just to roll things up what was done with this kernel.

1. Activated the usb-c code in the kernel.
2. Updated the realtek 8152 driver from version 1.9.9 to 2.12.0
3. Added the microsoft 8152 compatible hardware code to the downloaded r8152.c file
4. Recompiled the kernel using FOG configuration base file against the linux kernel 4.19.65.

[JJ Fullmer]

@george1421 Any reason you didn’t want to try compiling kernel version 5.1.16 ? Noticed that there’s one of those in the kernel update screen of fog configuration.

[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?