On Tue, Jun 21, 2011 at 10:56 PM, James Westby james.westby@linaro.org wrote:
On Tue, 21 Jun 2011 09:04:41 +0000, Fathi Boudra fathi.boudra@linaro.org wrote:
If not, what are the blockers to doing so?
Today, the builders are unstable. It requires:
- check the build status everyday as the notifications are broken.
Notifications are now working.
I can live with this manual steps in the short term but it should be fixed ASAP. It isn't a hard blocker as we have a (manual) workaround. Any other opinion?
IS are looking in to this problem. It is not confined to our slaves (at least they have found plenty of problems with unstable ARM boards.) The only info I have currently on it is the following kern.log snippet:
Jun 13 23:10:01 miraclefruit kernel: [67719.667022] Unhandled fault: external abort on non-linefetch (0x1018) at 0x40000000 Jun 14 23:10:01 miraclefruit kernel: [23044.748687] Unhandled fault: external abort on non-linefetch (0x1018) at 0x40313000 Jun 15 10:39:07 miraclefruit kernel: [64388.888458] usb 1-2.3: reset high speed USB device using ehci-omap and address 4
The unhandled fault shouldn't be related with the usb errors. From my experience with Beagle xM the USB port will trigger the reset once the disk is consuming more power than beagle can provide. As I know this is probably a powered USB disk, it'd be good to check the same hardware on another beagle to see if we're able to reproduce the problem, as in the end it could be just a normal hardware failure.
I've heard a rumour that the problems are related to the USB subsytem and the USB hard disks, but nothing more concrete than that. They are running beagleXMs for what it is worth.
Do you know why we're using beagle xM and not panda for the builders? It'd also be good to have the correct board revision ID to know if the xM is a prototype or a final release (A, A2, B or even C now).
Cheers,