Ticket #10221 (closed defect: fixed)

Opened 4 years ago

Last modified 4 years ago

XO-1 os300 no wireless data LED activity in default mesh connection

Reported by: Quozl Owned by:
Priority: normal Milestone: 10.1.2
Component: not assigned Version: Development build as of this date
Keywords: os300 Cc:
Action Needed: no action Verified: no
Deployments affected: Blocked By:


A set of four XO-1 were loaded with os300 and then booted. A mesh was formed automatically on wireless channel 1, and each XO icon was visible on the neighbourhood view of each other XO.

Chat was started and shared, and each laptop joined.

The wireless activity LED would normally (8.2.1) be lit when chat text is sent. On os300 it is not lit.

(iwpriv eth0 ledgpio no longer responds in the same fashion it did under previous XO-1 stable kernel)


Change History

Changed 4 years ago by mikus


Two years ago I gave up on making sense of the LEDs. It would have been nice if they had conveyed status information to the user -- but from my experience I concluded that an LED being 'on' or 'pulsing' or 'rapid blink' or even 'off' -- did NOT reliably mean anything. Some (e.g., Kim Quick) were able to correlate LED usage with at least "wireless is working" -- but not I.

My conclusion then was that the LEDs meant something to a Marvell diagnostician -- but not to an OLPC user. If I was correct in observing that the LEDs did not reliably convey "state" -- why write a ticket now -- to the best of my recollection, no new code (e.g., for LED usability improvement) has ever been added (in these past two years).

Changed 4 years ago by dsd

It took me about 10 minutes to bring forward the private ioctls again. I dropped the WOL ones which were trickier to compile. The result works and solves this bug, I didn't test other ioctls. The code isn't nice but at least its not really a maintenance headache. Any objections to this patch?

Changed 4 years ago by dsd

Changed 4 years ago by Quozl

Daniel, any chance of adding in #9988 (disk activity light doesn't work) so that both XO-1 and XO-1.5 new releases follow the original design?

In other words, rather than treating this as a regression against 8.2.1, could we steal the second LED and use it for storage (NAND or SD) activity?

Changed 4 years ago by dsd

Pretty sure the original design was that this LED is for the mesh. #9988 would be a big task for me (lots of learning to do) and I don't have so much time to dedicate.

I think we should restore this as the mesh LED at least until we have code ready to make it a disk indicator.

Changed 4 years ago by dsd

  • next_action changed from diagnose to add to build

I think we're all in agreement, this would be more useful as a disk indicator but the code doesn't exist yet. For now I have restored the ioctls to make it a mesh LED.

Changed 4 years ago by dsd

  • next_action changed from add to build to test in build

test in upcoming os301

Changed 4 years ago by Quozl

  • milestone changed from 1.0-software-update to 10.1.2

Changed 4 years ago by Quozl

  • keywords os300 added
  • status changed from new to closed
  • next_action changed from test in build to no action
  • resolution set to fixed

Tested in os301 XO-1, wireless LEDs behave in same fashion as on 8.2.1. Closing.

Note: See TracTickets for help on using tickets.