Did you run out of memory? This is the only explanation I have. Please check free memory when httpd crashes.
That I didn't. I did check flash space (df -k), and that looked fine... I can get this problem to re-occur, so once I get it happening again, I'll check system resources.
I've also found a permanent workaround for it: since telnet works, one can telnet in and then do "mtd erase nvram && reboot" (at least on a WRT54GL v1.1). The next time (and all subsequent times) the unit restarts, the web interface works great.
I've also found a permanent workaround for it: since telnet works, one can telnet in and then do "mtd erase nvram && reboot" (at least on a WRT54GL v1.1). The next time (and all subsequent times) the unit restarts, the web interface works great.
Look, look, you've reinvented the wheel, i.e. "restore to factory defaults".
As it was said 1000000000000 times this is must to do when upgrading.
No bug then.
Look, look, you've reinvented the wheel, i.e. "restore to factory defaults".
As it was said 1000000000000 times this is must to do when upgrading.
No bug then.
Can you explain why holding in the reset button on the back of the GL then power cycling the unit, holding the button in for 30 seconds, then letting go *does not* solve the problem then?
Also, I've managed to get online while the unit has no working httpd (I wasn't able to before, maybe I was being impatient waiting for my cable modem to delegate DHCP). Resources are fine:
Code:
DD-WRT VeryBusyBox v1.2.1 (2006.09.15-17:59+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
~ # ps
PID Uid VmSize Stat Command
1 root 368 S /sbin/init noinitrd
2 root SW [keventd]
3 root SWN [ksoftirqd_CPU0]
4 root SW [kswapd]
5 root SW [bdflush]
6 root SW [kupdated]
11 root SW [mtdblockd]
14 root 240 S /sbin/watchdog
62 root 292 S resetbutton
92 root 384 S /usr/sbin/telnetd
95 root 468 S httpd
105 root 336 S dnsmasq --conf-file /tmp/dnsmasq.conf
108 root 288 S /sbin/wland
144 root 280 S /usr/sbin/cron
152 root 368 S upnp -D -L br0 -W vlan1 -I 60 -A 180
153 root 268 S udhcpc -i vlan1 -p /var/run/udhcpc.pid -s /tmp/udhcpc
164 root 512 S /tmp/udhcpc bound
288 root 328 S process_monitor
290 root 516 S -sh
291 root 408 R ps
{---
visited web page -- got back blank page, HTML is this:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
---}
Do you have a statically-linked strace binary that works with DD-WRT that I could download and use? I can probably figure out what's causing this if I had strace and possibly gdb...
It seems that crashes on language selection.
Please give me
nvram get language
Please re-open the Bugtracker that you closed last night. I'll reproduce the problem later today and provide you the contents of NVRAM that you want (I'll also attach the results for an "nvram show" to the bug once I have them).
Also, how did you debug this? I can't find a single debugging tool that works on DD-WRT. strace complains about the ptrace(2) syscall missing, which means that someone built the kernel without 4.3BSD ptrace support. This is bad.
Joined: 11 Jul 2006 Posts: 1247 Location: Nijmegen, The Netherlands
Posted: Wed Sep 20, 2006 15:55 Post subject:
koitsu wrote:
Can you explain why holding in the reset button on the back of the GL then power cycling the unit, holding the button in for 30 seconds, then letting go *does not* solve the problem then?
HARD reset is done on a running router eg:
You are logged in on the console or the GUI or should be able to do so.
NOW press resetbutton for 30 seconds...
HARD reset is done on a running router eg:
You are logged in on the console or the GUI or should be able to do so.
NOW press resetbutton for 30 seconds...
Joined: 11 Jul 2006 Posts: 1247 Location: Nijmegen, The Netherlands
Posted: Wed Sep 20, 2006 16:03 Post subject:
Eko wrote:
rkloost wrote:
HARD reset is done on a running router eg:
You are logged in on the console or the GUI or should be able to do so.
NOW press resetbutton for 30 seconds...
Wrong --- doesn't matter if you're logged in.
"or should be able to do so" IMHO implicitly means the router should be in a
semi-stable state, in which you can access the router.
"or should be able to do so" IMHO implicitly means the router should be in a
semi-stable state, in which you can access the router.
But these are semantics.
Actually it's not semantics -- Eko is correct (you do not need to be logged in to accomplish any of this).
From what I remember, CFE/PMON actually does some magic as far as checking the button and emptying out NVRAM (either entirely or resetting it to some hard defaults -- which you get depends on what model of unit you have and what revision (my WRT54Gv2 empties out NVRAM entirely, while my WRT54GL and WRT54GS units empty it out and set a bunch of default values). You can't get this to happen while the unit is up and running (because CFE/PMON isn't engaged at that point, the kernel is already loaded).
If there's a "hold the reset button on the back of the router for 30 seconds" solution *while the kernel is loaded*, that's news to me.
Eko, can you confirm that the "hold button for 30 seconds while unit is running" method does something other than simply reboot the unit? I imagine the reason it works is because holding down the button while the kernel is loaded results in a unit reset, then since the user is holding the button still, CFE/PMON sees this and does what I described above...
