issue with netcard of dock gen2 of lenovo l390

[george1421]

@Developers here is what I did

1. Probably not related to the issue at hand. Enabled usb-c support in the kernel. The kernel was 4.19.65
   enable_usb-c.patch.txt

2. I downloaded the 2 files from this url: https://github.com/wget/realtek-r8152-linux and copied them to linux-4.19.65/drivers/net/usb/ overwriting what was there (note I appended .txt to allow uploading to the forum).
   r8152.c.txt
   compatibility.h.txt

3. Recompiled the kernel using the 1.5.7 base config file from the fos github site.

[JJ Fullmer]

@george1421
I would probably bet that adding usc-c support helped more than we know. I’ve just never had this good of an experience with a usb-c adapter and fog. Just my 2 cents.

Do you see any reason that one shouldn’t use this kernel for all devices?

Also, another side note to my Fellow Lenovo L390 owners. If you set the Mac Address Passthrough option in the bios to “Second Mac Address” you can get a unique mac address for each device that uses that usb-c adapter or dock to image with fog so you won’t have issues with duplicate macs. However if you set it to “Internal Mac Address” it replicates the internal card which confuses ipxe that there are 2 network cards with the same mac address and it tries a ‘net0’ device twice failing both times.

[george1421]

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

Do you see any reason that one shouldn’t use this kernel for all devices?

There is no reason why you shouldn’t use this kernel. This is exactly the same kernel that ships with FOG 1.5.7 with the exception of the updated realtek driver and adding in the usb-c stuff.

I started with the default FOS Linux settings for 1.5.7 and made the changes I posted. This was done so that the devs could duplicate what was done during our testing.

I’ve just never had this good of an experience with a usb-c adapter and fog

It would be interesting to see if your experiences with usb-c change with this kernel.

[JJ Fullmer]

@george1421 I’m making it my default kernel now then, I backed up the old one of course. I’ll report back if there are any problems, but I would assume all will work as expected.

[JJ Fullmer]

@george1421 so some odd things to report with the new kernel as the default…
One almost plus, I found that an acer switch 3 recognized the lenovo usb-c ethernet adapter as one that could pxe boot. It even almost worked but it is now frozen at ipxe initialising devices... In the past, no usb-c ethernet adapter would do a native pxe boot on this device, so that’s something. I guess I still don’t have one that will do a pxe boot.

I went to image a new surface go with the microsoft usb-c ethernet adapter that was working in the past.
I got this message after pxe boot completed and FOS was starting…

Sorry that it’s blurry, basically it says that the kernel is probably missing the correct driver. Doesn’t make a ton of sense that the fix for one usb-c ethernet adapter would break another. It isn’t impossible that microsoft’s adapter also uses a realtek chip and this chip doesn’t like the new driver. Why can’t they all just get along?

I will try testing the old kernel and other things tomorrow.

[JJ Fullmer]

@george1421 I did do a test on a normal device (intel ethernet desktop type) and it did boot to the fog menu and started an image deploy without a problem on the new kernel. I set the surface go to use the old kernel (I have so many now I’m not actually 100% sure which one it is, but pretty sure its the one that shipped with 1.5.7) and it is now imaging properly, meaning that the new kernel does indeed fix one usb-c adapter and breaks a different one. I’ll get the details on the microsoft ethernet adapter if you want them tomorrow.

[george1421]

@JJ-Fullmer Well what I can do is this. I can reset the FOS Linux kernel back to 4.19.65 base then only apply the usb-c changes to see if its the realtek driver or the usb-c changes causing the troubles. If you have the hardware to test on.

The other thing as like you said, we’ll need the nic vendor and hardware ID either from windows or via FOS Linux lspci or lsusb depending on how the nic is attached.

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