Matt has also reported sluggish dhcp response in the lng lab so we should
check if the lab server is performing aceptably.
On Oct 11, 2013 7:10 PM, "Kim Phillips" <email address hidden> wrote:
> I seem to have found a potential fixto the problem in the LAVA lab.
> I've since gone from 100% failure to 100% success, although I've only
> tried two so far :) :
>
> http://validation.linaro.org/scheduler/job/78394/log_file#L_29_365
>
> http://validation.linaro.org/scheduler/job/78390/log_file#L_29_368
>
> the change I made was to the bin/busybox.nosuid binary:
>
> -udhcpc -R -n -p /var/run/udhcpc.%iface%.pid -i %iface%
> +udhcpc -t 10 -p /var/run/udhcpc.%iface%.pid -i %iface%
>
> that is, omit the:
>
> -n,--now Exit with failure if lease is not immediately obtained
>
> and jack up the retries parameter:
>
> -t,--retries=N Send up to N request packets
>
> (although I can't tell what the default retries is).
>
> for more info on the parameters, go to
> http://busybox.net/downloads/BusyBox.html and search the page for udhcp.
>
> The fix-vs.-workaround argument here is that the lab's DHCP server has
> a much higher latency than local development systems. If that's
> acceptable, we need to amend the rootfs build to perform the above
> changes in the busybox configuration. Any tips on where that lives in
> the massively overloaded meta-maze called OE would be appreciated.
>
> If not, I'd like to request root access to the DHCP server for
> diagnostics.
>
> --
> You received this bug notification because you are a member of Linaro
> Networking Group, which is subscribed to linaro-networking.
> Matching subscriptions: LNG all, all issues
> https://bugs.launchpad.net/bugs/1234718
>
> Title:
> kernel linux-lng-preempt-rt wont boot kvm guest when hugepages are
> enabled
>
> Status in Linaro networking Group:
> Triaged
>
> Bug description:
> when enabling hugepages in the kernel the kvm guest does not boot.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/linaro-networking/+bug/1234718/+subscriptions
>
Matt has also reported sluggish dhcp response in the lng lab so we should
check if the lab server is performing aceptably.
On Oct 11, 2013 7:10 PM, "Kim Phillips" <email address hidden> wrote:
> I seem to have found a potential fixto the problem in the LAVA lab. validation. linaro. org/scheduler/ job/78394/ log_file# L_29_365 validation. linaro. org/scheduler/ job/78390/ log_file# L_29_368 udhcpc. %iface% .pid -i %iface% udhcpc. %iface% .pid -i %iface% busybox. net/downloads/ BusyBox. html and search the page for udhcp. /bugs.launchpad .net/bugs/ 1234718 preempt- rt wont boot kvm guest when hugepages are /bugs.launchpad .net/linaro- networking/ +bug/1234718/ +subscriptions
> I've since gone from 100% failure to 100% success, although I've only
> tried two so far :) :
>
> http://
>
> http://
>
> the change I made was to the bin/busybox.nosuid binary:
>
> -udhcpc -R -n -p /var/run/
> +udhcpc -t 10 -p /var/run/
>
> that is, omit the:
>
> -n,--now Exit with failure if lease is not immediately obtained
>
> and jack up the retries parameter:
>
> -t,--retries=N Send up to N request packets
>
> (although I can't tell what the default retries is).
>
> for more info on the parameters, go to
> http://
>
> The fix-vs.-workaround argument here is that the lab's DHCP server has
> a much higher latency than local development systems. If that's
> acceptable, we need to amend the rootfs build to perform the above
> changes in the busybox configuration. Any tips on where that lives in
> the massively overloaded meta-maze called OE would be appreciated.
>
> If not, I'd like to request root access to the DHCP server for
> diagnostics.
>
> --
> You received this bug notification because you are a member of Linaro
> Networking Group, which is subscribed to linaro-networking.
> Matching subscriptions: LNG all, all issues
> https:/
>
> Title:
> kernel linux-lng-
> enabled
>
> Status in Linaro networking Group:
> Triaged
>
> Bug description:
> when enabling hugepages in the kernel the kvm guest does not boot.
>
> To manage notifications about this bug go to:
> https:/
>