Opened 4 years ago

Closed 4 years ago

#10221 closed defect (fixed)

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:
Blocked By: Blocking:
Deployments affected: Action Needed: no action
Verified: no

Description

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)

Attachments (1)

0001-libertas-readd-private-ioctls-again.patch (42.0 KB) - added by dsd 4 years ago.

Download all attachments as: .zip

Change History (9)

comment:1 Changed 4 years ago by mikus

Disclaimer: METACOMMENT

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).

comment:2 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?

comment:3 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?

comment:4 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.

comment:5 Changed 4 years ago by dsd

  • Action Needed 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.

comment:6 Changed 4 years ago by dsd

  • Action Needed changed from add to build to test in build

test in upcoming os301

comment:7 Changed 4 years ago by Quozl

  • Milestone changed from 1.0-software-update to 10.1.2

comment:8 Changed 4 years ago by Quozl

  • Action Needed changed from test in build to no action
  • Keywords os300 added
  • Resolution set to fixed
  • Status changed from new to closed

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.