Opened 10 years ago

Closed 9 years ago

#3552 closed defect (fixed)

strange LED behaviour on WGT634U

Reported by: cozmic Owned by: florian
Priority: low Milestone: Kamikaze 8.09.1
Component: kernel Version:
Keywords: Cc:


With the latest version r11461 the LEDs on my router show a strange behaviour:

The switch LEDs for port 1 and WAN port turn orange when the kernel initializes the switch at startup. They are green during CFE phase and stayed green with my old version of openwrt (5xxx).
I did not see any functional defect, though - port 1 is working at 100 MBps.

The power LED flashes amber during operation. It's not the flashing algorithm of the diag module. The timing is pulse - short - pulse - long.
Repeated queries of /proc/diag/led/power return usually 1, but sometimes 0, probably when you hit the pulse.
When I set the /proc/diag/led/power to f(lash), it flashes irregular and I always read f afterwards.
The flashing appears also when the kmod-diag is not installed, so I assume something else triggers this flashing.

Attachments (0)

Change History (13)

comment:1 Changed 10 years ago by anonymous

I can confirm this bug. It's been there since at least April, 2008.

comment:2 Changed 10 years ago by anonymous

Nominate this bug for milestone Kamikaze 808 RC-1

comment:3 Changed 10 years ago by agb

  • Milestone changed from Kamikaze to Kamikaze 808 RC-1

comment:4 follow-up: Changed 10 years ago by anonymous

Could you try tracking down the exact changeset made to the brcm47xx GPIO code which is certainly the origin of this issue ?

comment:5 in reply to: ↑ 4 Changed 10 years ago by gwirth79@…

I have the same problem under r11744

This looks like it comes from the CONFIG_LEDS_TRIGGER_HEARTBEAT=y configuration option in the kernel config: trunk/target/linux/generic-2.6/config-default

This is also set in all the other configs (found using grep):

Looking at what can trigger the power LED shows the following

root@OpenWrt:/tmp# cat /sys/devices/platform/leds-gpio/leds/power/trigger

none timer [heartbeat] default-on morse

So we see that [heartbeat] is an explicit trigger.

Any way to turn that off at runtime?

comment:6 Changed 10 years ago by gwirth79@…

The origin of this issue is NOT gpio code. The fault was introduced in r10531.

The switch_robo kernel module was updated from 0.01 to 0.02. Actual file is /trunk/package/switch/src/switch-robo.c In the process, a function called robo_switch_enable has the following lines when the switch is successfully enabled:

        /* WAN port LED */
        robo_write16(ROBO_CTRL_PAGE, 0x16, 0x1F);

Apparently one of the values for writing to the control page is incorrect. I don't have the technical specs for the chip to figure out what should really be there.

comment:7 Changed 10 years ago by gwirth79@…

I figured out the heartbeat issue and it turns out to be a trivial fix. In the kernel documentation there is a file Documentation/leds-class.txt that discusses LED control. The sysfs entry for the triggers is shown by doing:

# cat /sys/devices/platform/leds-gpio/leds/power/trigger

and you get the response similar to:

none timer [heartbeat] default-on morse

Each of those items represents a choice for what can trigger the power LED. The current choice is in brackets, which by default is the [heartbeat]. If you want to change what can trigger the LED you can just echo the choice name into the trigger file like this:

# echo none > /sys/devices/platform/leds-gpio/leds/power/trigger

The different triggers do the following:

none - turns off the power (yellow) LED

timer - responds to system timer event

heartbeat - causes the power LED to pulse

default-on - turns the power LED on all the time

morse - flashes the LED in Morse code

If you set the LED trigger to "none" you can then control it through the /proc interface like so:

# echo 1 > /proc/diag/led/power

comment:8 Changed 9 years ago by cozmic

Looking at this spec:, page 00h addr 16h is in the reserved address range between 0x10 and 0x20 (page 103).
It's probably not a good idea to write there for the wgt634u.

comment:9 Changed 9 years ago by cozmic

Removing the line from switch-robo.c and using the trigger trick, I get the old behaviour - just green LEDs :)
Thanks for the information.

comment:10 Changed 9 years ago by MMCM <mmcm@…>

The bug with the WAN and LAN1 LEDs turning amber is still present in 8.09 RC2.
I think this should be fixed before releasing 8.09 final!

comment:11 Changed 9 years ago by anonymous

I concur, this bug is still present in RC2

comment:12 Changed 9 years ago by florian

  • Component changed from packages to kernel
  • Milestone changed from Kamikaze to Kamikaze 8.09.1
  • Owner changed from developers to florian
  • Priority changed from normal to low
  • Status changed from new to assigned

Bug confirmed.

comment:13 Changed 9 years ago by florian

  • Resolution set to fixed
  • Status changed from assigned to closed

Fixed with [15290]. Thanks for narrowing down the bug.

Add Comment

Modify Ticket

as closed .
The resolution will be deleted. Next status will be 'reopened'.

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.