Re: [Xen-devel] rochester and Debian buster
Julien Grall writes ("Re: rochester and Debian buster"):
> I have just remembered that we are not using the on-board network card but
> instead a USB dongle.
Yes.
> But I am not sure which eth interface is linked to and how you found
> out the network is down.
I didn't have clear notes about this so I decided to repro the
problem. I reran my setup, and it *passed*, installing buster
successfully on rochester1. This is very odd and I can't explain it.
The two jobs' (143098 vs 143287) runvars are identical apart from the
syslog server port (which is expected to vary) and the
`host_power_install' which is only set after a successful boot into
the installer. The database records the previous one as `broken' and
the new one as `pass'. The osstest revision was identical. My
previous test run, that failed, was a really quite formal
mg-repro-setup run, so I don't think it had any kind of weirdness that
would explain the symptoms.
My recollection is that both `ip link show' and kernel log messages
agreed that there was no NIC with a working network link. I don't
recall how many were detected but I think I looked at the MAC address
from the osstest configuration and saw it in the list from the
machine.
> I am not entirely sure whether this would help because I have had
> report that Debian Buster has been installed successfully on
> Thunder-X.
Well, now you have a second.
I have not done enough of these install attempts to know if there is
some kind of heisenbug here. The situation seems concerning. I guess
for now I will carry on and see if it does it again...
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] rochester and Debian buster
Hi Ian, On 24/10/2019 16:47, Ian Jackson wrote: We discussed on irc the problems I have been having trying to get buster's released kernel to run on the rochesters, which is wanted to upgrade osstest to buster (which is currently Debian stable). Unfortunately our previous conversations don't seem to have been recorded anywhere. Let's try at least to write things down now. The symptom is that the machine thinks the network link is down, and no network stuff happens, so the installer doesn't work. (I don't think I have checked at the switch end whether the link is actually up.) I have just remembered that we are not using the on-board network card but instead a USB dongle. Looking at the log, it looks like the kernel found the dongle: Oct 24 10:57:31.499085 [ 14.421064] asix 3-1.3:1.0 eth5: register 'asix' at usb-:00:11.0-1.3, ASIX AX88772B USB 2.0 Ethernet, 00:50:b6:22:00:67 But I am not sure which eth interface is linked to and how you found out the network is down. You suggested that maybe adding iommu.passthrough=1 to the kernel command line might help. But it hasn't. I have a memory of discussing the next steps and I think we discussed upgrading the firmware. If I remember rightly we agreed (with Juergen) that upgrading the firmware on one of the two rochester machines would be an acceptable risk. Can we file a ticket to have that done by our onsite technician ? I am not entirely sure whether this would help because I have had report that Debian Buster has been installed successfully on Thunder-X. Anyway, updating the firmware to something more recent would be good. We are currently using T48, and the most recent seems to be F02 [1]. It is not entirely clear to me what's the difference between the Txx and Fxx release. I have asked some help and will let you know. Cheers, [1] https://www.gigabyte.com/ARM-Server/R150-T61-rev-110/support#support-dl-bios -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] rochester and Debian buster
We discussed on irc the problems I have been having trying to get buster's released kernel to run on the rochesters, which is wanted to upgrade osstest to buster (which is currently Debian stable). Unfortunately our previous conversations don't seem to have been recorded anywhere. Let's try at least to write things down now. The symptom is that the machine thinks the network link is down, and no network stuff happens, so the installer doesn't work. (I don't think I have checked at the switch end whether the link is actually up.) You suggested that maybe adding iommu.passthrough=1 to the kernel command line might help. But it hasn't. I have a memory of discussing the next steps and I think we discussed upgrading the firmware. If I remember rightly we agreed (with Juergen) that upgrading the firmware on one of the two rochester machines would be an acceptable risk. Can we file a ticket to have that done by our onsite technician ? Other options would include trying a buster-backports kernel, if we had some reason to think that a newer kernel would be better. Certainly if this turns out to be a kernel bug, and a workaround is awkward, the best fix would be to get the bugfix backported to the Debian buster kernel (either the stable series, or -backports). Currently I have rochester1 booked out and you are free to play with it if you like. We'll negotiate about that on irc. Ian. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
