Bug 1615252

Created attachment 1475491 [details]
Screenshot-2

Created attachment 1475493 [details]
Screenshot-3

Additional information for this bug:
1. On virt-p2v client page, turn to command line page:
# ip a 
->only lo shows

Then check network driver 'tg3' existence

# lsmod |grep tg3

Try to load tg3 module manually.
# modprobe  tg3
[root@client ~]# lsmod |grep tg3
tg3                   174781  0 
ptp                    19231  1 tg3

After i load tg3 driver manually, then eth0 can get network and can connect to conversion server successfully.

So rjones, could you help me have a look of this case, why tg3 dirver cannot load automatically on my host, thanks.

Sorry I missed this one; is it possible to get the complete dmesg from
the host?

Created attachment 1478430 [details]
dmesg on my host until i load tg3 driver manually

(In reply to Richard W.M. Jones from comment #5)
> Sorry I missed this one; is it possible to get the complete dmesg from
> the host?

Hi rjones,
I have attached dmesg file on host until i load tg3 driver manually, please have a look, thanks.

I see a few bugs about BCM5719 not being recognized at boot,
but none of them have a resolution.

Could you collect:

# lspci -vvv

from the machine?

Created attachment 1478437 [details]
reply for lspci -vvv output

Don Dutile asks:

Is the PCI ID (14e4:1657) in the
/lib/modules/<kernel-version>/modules.alias file?

Do you ever see a message like this in the logs:

tg3: No firmware

Also could you check:

# lsinitrd -k $(uname -r) |grep tg3

(In reply to Richard W.M. Jones from comment #14)
> Also could you check:
> 
> # lsinitrd -k $(uname -r) |grep tg3

Output for this command is none, thanks.

(In reply to Richard W.M. Jones from comment #13)
> Do you ever see a message like this in the logs:
> 
> tg3: No firmware

I checked again, so tg3 related message in /var/log/dmesg, thanks.

(In reply to Richard W.M. Jones from comment #12)
> Don Dutile asks:
> 
> Is the PCI ID (14e4:1657) in the
> /lib/modules/<kernel-version>/modules.alias file?

Yes, it is.
alias pci:v000014E4d00001657sv*sd*bc*sc*i* tg3

Is there anything interesting in the full logs?  Can you run this
command and attach the full log:

# journalctl > /var/tmp/log

Created attachment 1479209 [details]
journalctl.log

The only thing we spotted which looks suspicious/bad is:

Aug 27 08:19:21 localhost systemd-udevd[775]: worker [786] /devices/pci0000:00/0000:00:1c.0/0000:02:00.0 is taking a long time
Aug 27 08:19:21 localhost systemd-udevd[775]: worker [787] /devices/pci0000:00/0000:00:1c.0/0000:02:00.1 is taking a long time
Aug 27 08:19:21 localhost systemd-udevd[775]: worker [788] /devices/pci0000:00/0000:00:1c.0/0000:02:00.2 is taking a long time
Aug 27 08:19:21 localhost systemd-udevd[775]: worker [789] /devices/pci0000:00/0000:00:1c.0/0000:02:00.3 is taking a long time

and then a couple of minutes later:

Aug 27 08:21:21 localhost systemd-udevd[775]: worker [786] /devices/pci0000:00/0000:00:1c.0/0000:02:00.0 timeout; kill it
Aug 27 08:21:21 localhost systemd-udevd[775]: seq 3353 '/devices/pci0000:00/0000:00:1c.0/0000:02:00.0' killed
Aug 27 08:21:21 localhost systemd-udevd[775]: worker [787] /devices/pci0000:00/0000:00:1c.0/0000:02:00.1 timeout; kill it
Aug 27 08:21:21 localhost systemd-udevd[775]: seq 3354 '/devices/pci0000:00/0000:00:1c.0/0000:02:00.1' killed
Aug 27 08:21:21 localhost systemd-udevd[775]: worker [788] /devices/pci0000:00/0000:00:1c.0/0000:02:00.2 timeout; kill it
Aug 27 08:21:21 localhost systemd-udevd[775]: seq 3355 '/devices/pci0000:00/0000:00:1c.0/0000:02:00.2' killed
Aug 27 08:21:21 localhost systemd-udevd[775]: worker [789] /devices/pci0000:00/0000:00:1c.0/0000:02:00.3 timeout; kill it
Aug 27 08:21:21 localhost systemd-udevd[775]: seq 3356 '/devices/pci0000:00/0000:00:1c.0/0000:02:00.3' killed

However there's no further information about why exactly those udev processes
were taking a long time.

I still think this is some sort of kernel/systemd issue and not really related
to virt-p2v.

Is it possible you could check the firmware version of the Broadcom
card, and if necessary update it?  See:
https://bugzilla.redhat.com/show_bug.cgi?id=1618856#c9

Sorry, that's actually a different Broadcom card, so those
firmware images are probably not relevant.

However it might be good to check that the card is using the
latest possible firmware.  If you have troubles finding it
let me know and I'll see if I can find something.

After discussion with the reporter we believe that this bug
is caused by using a virtual CD which is located (physically)
very far from the blade which is running virt-p2v.  This
causes long delays when running udev jobs, causing the
timeouts observed.

You can change the timeout on the kernel command line by adding:

  udev.event-timeout=6000

But in the meantime this is not really a bug that we can fix
easily in virt-p2v.

Possibly the udev default timeout could or should be changed to
be longer.

(In reply to Richard W.M. Jones from comment #23)
> After discussion with the reporter we believe that this bug
> is caused by using a virtual CD which is located (physically)
> very far from the blade which is running virt-p2v.  This
> causes long delays when running udev jobs, causing the
> timeouts observed.
> 
> You can change the timeout on the kernel command line by adding:
> 
>   udev.event-timeout=6000
> 
> But in the meantime this is not really a bug that we can fix
> easily in virt-p2v.
> 
> Possibly the udev default timeout could or should be changed to
> be longer.

Hi rjones,
If i understand you correctly, we have to add timeout option on the kernel command line, then check on virt-p2v client page, it means, if we run
# cat /proc/cmdline
initrd=initrd0.img root=live:CDLABEL=virt-p2v-1.38.2-5.el7 rootfstype=auto ro rd.live.image quiet console=tty0 console=ttyS0,115200 rd_NO_PLYMOUTH net.ifnames=0 rd.luks=0 rd.md=0 rd.dm=0  BOOT_IMAGE=vmlinuz0 

then we can see timeout option, right? 
But i don't know where to set it, i tried set timeout on p2v host which we want to convert, but it seems meaningless, it also failed to 'Test Connection' on virt-p2v client, could you give me some more detail information, thanks.

When the virt-p2v ISO boots, interrupt the boot at the kernel screen.
You should be able to edit the kernel command line to add the
udev.event-timeout setting.

1.Adding udev.event-timeout=6000 into kernel command line via interrupting virt-p2v booting, 

2.Found there is only network "eth1" after booting into p2v client, and eth1 can't obtain IP, actually, eth0 is linked the network port, so modify the network script to change network name from eth1 to eth0

3.Both eth0 and eth1 can load tg3 module automatically

4.But eth0 still can't obtain IP and service network can't start,pls refer to screenshot "add-udev"

Created attachment 1491530 [details]
add-udev

While it's unfortunate that we still cannot make virt-p2v work, I
would say that _this_ bug (cannot load tg3 driver) has indeed been
fixed by using the longer udev timeout.  This appears to confirm the
theory in comment 23.

Is it possible that you can test this using a virtual CD which
isn't located so far away from the actual system?  Although we have
fixed the udev problem, these lengthy delays could cause other
issues -- for example it is plausible that udev now loads the
correct driver, but it does it so late in the boot process that
NetworkManager (or whatever is responsible for the network) has
already started, or NM itself is timing out, or something like that.

Hi rjones,

   Sorry, I missed this needinfo, as comment8 shown, network has no problem in p2v client when p2v iso is mounted on virtual media via beijing URL and image file.

Closing per comment 23 etc.