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: |
Description
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.
Attachments (0)
Change History (13)
comment:1 Changed 10 years ago by anonymous
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: ↓ 5 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):
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?
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: 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.
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.
I can confirm this bug. It's been there since at least April, 2008.