strange LED behaviour on WGT634U

[cozmic]

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

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

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

[anonymous]

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

[anonymous]

Nominate this bug for milestone Kamikaze 808 RC-1

[anonymous]

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

[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):
trunk/target/linux/generic-2.6/config-2.6.22:CONFIG_LEDS_TRIGGER_HEARTBEAT=y
trunk/target/linux/generic-2.6/config-2.6.23:CONFIG_LEDS_TRIGGER_HEARTBEAT=y
trunk/target/linux/generic-2.6/config-2.6.24:CONFIG_LEDS_TRIGGER_HEARTBEAT=y
trunk/target/linux/generic-2.6/config-2.6.25:CONFIG_LEDS_TRIGGER_HEARTBEAT=y
trunk/target/linux/generic-2.6/config-2.6.26:CONFIG_LEDS_TRIGGER_HEARTBEAT=y

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?

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

[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

[cozmic]

Looking at this spec: ​http://voodoowarez.com/bcm5365p.pdf, 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.

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

[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!

[anonymous]

I concur, this bug is still present in RC2

[florian]

Bug confirmed.

[florian]

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