So ... my router WAS working just fine, but today it has crashed at least 8 times, all requiring reboots ... *sigh*

This problem should be fixed as fast as possible, as it makes a lot users routers unusable. What can I do to help the devs?

Does Kamikaze suffer from this issue? This would be a possible workround at least for me.

WRT54GL: Kamikaze (2.4 Kernel) uses the latest Broadcom wl driver (4.80.53.0) WhiteRussion uses 3.90.37.0. So chances exist that Kamikaze does not suffer from this issue because Broadcom may have fixed it. However I cannot test it since my setup is not Kamikaze-compatible.

The alternative (which I could test) would be to create a version of WR which includes the latest wl. Since I am not good on compiling I haven't had a chance to play to find what exactly has to be compiled into a new WR image to make the new wl system work in WR. Just replacing wl.o does not work (see my previous posts).

(Last edited by lc on 29 Mar 2007, 15:09)

@sammy2000:

If you don't mind trying a Kamikaze version, then please have a look here:
http://downloads.openwrt.org/snapshots/brcm47xx-2.6/

This is the Kamikaze package with Kernel 2.6, it uses a GPL module for the Broadcom hardware. This module seems to be quite stable now, so it's worth a try. I'll have a look at it in week or so. The Kamikaze package for Kernel 2.4 uses the binary only module from Broadcom, it is a different version to the one used in White Russian, but it's still a closed source Broadcom module.

I'm very interested in your Kamikaze results, and I'll post mine here, too.

no, broadcom wifi is not supported yet, so don't bother trying

Thanks for clarifying that, I think I mixed it up with brcm47xx-2.6 while reading your last note on this ticket:
https://dev.openwrt.org/ticket/1312

Hey everybody, I've written a short script that may or may not help with the stability issues. It adds some of the nvram fixups found in the Linksys firmware.
http://nbd.name/nvram-fixup.sh

Please note that this hasn't been tested very much, so don't blame me if it crashes your router, eats your dog for breakfast or burns down your house.

Thanks nbd, I'll try it.
Btw, a finalising "nvram commit" is necessary, isn't it?

Thanks for the script! I ran it on a few systems (WRT54GL v1.1, boardflags=0x2558) that reboot quite often.

On systems with (intentionally) reduced tx power it turned up the tx power to the factory value, no other changes:

Checking Linksys WRT54G* fixups...
Adding fixups for BCM5352E
nvram: pa0maxpwr: '0x05' -> '0x4e'

On systems operating at 0x4e tx power there are no changes at all:

Checking Linksys WRT54G* fixups...
Adding fixups for BCM5352E

Since also the 0x4e tx power systems suffer from the kernel panic / reboot problem I am afraid this is no remedy

Thanks nbd for the script.

I have also tried using it on a WRT54GL 1.1.

No nvram settings were changed, so as lc said this is no remedy.

(Last edited by kebab on 29 Mar 2007, 20:48)

I hope I'll have more luck than you two guys, I tested the script a few minutes ago on four access points, and it changed the NVRAM var 'opo' from '0x02' to '0x0008' on all of them. Anyone knows what 'opo' is responsible for?

Maybe my WRTs won't hang anymore and start to reboot like yours now ;-). It would be a great leap forward for me and my installation...

Thanks nbd for posting that.

On my WRT54GL:

root@OpenWrt:/etc# ./nvram-fixup.sh
Checking Linksys WRT54G* fixups...
Adding fixups for BCM5352E
nvram: opo: '0x02' -> '0x0008'
root@OpenWrt:/etc#

I just committed that and rebooted, hopefully it will help.

If not, I may backup my current install and try a Kamikaze snapshot.

(Last edited by Duon on 29 Mar 2007, 22:09)

The opo setting on my WRT54GL was already set to 0x0008, so I suspect this will not make any difference. This router occasionally reboots, but mainly crashes.

Thanks for dashing my hopes ;-)...

please show me the output of 'nvram show | grep sdram'

This is from one of my favourite crashers:

nvram show | grep sdram
size: 1838 bytes (30930 left)
sdram_config=0x0062
sdram_refresh=0x0000
sdram_ncdl=0xfe0008
sdram_init=0x010b

This is from one of my rebooting/crashing WRT54GL 1.1 routers:

sdram_config=0x0062
size: 10535 bytes (22233 left)
sdram_refresh=0x0000
sdram_ncdl=0xfe0009
sdram_init=0x010b

(Last edited by kebab on 29 Mar 2007, 23:05)

This is from one of my Buffalo WHR-G54S routers that reboots quite regularly.

size: 1214 bytes (31554 left)
sdram_config=0x22
sdram_refresh=0
sdram_ncdl=0x1f
sdram_init=0x0100

(Last edited by kebab on 29 Mar 2007, 23:05)

From my WRT54GL v1.1, which has been crashing for the last couple of days (stable so far today, fingers crossed):

sdram_config=0x0062
sdram_refresh=0x0000
sdram_ncdl=0xfe0108
sdram_init=0x010b

From a few WRT54GLs who all have the usual symptoms:

size: 10082 bytes (22686 left)
sdram_config=0x0062
sdram_refresh=0x0000
sdram_ncdl=0xff0109
sdram_init=0x010b

size: 10124 bytes (22644 left)
sdram_config=0x0062
sdram_refresh=0x0000
sdram_ncdl=0xff0108
sdram_init=0x010b

size: 10081 bytes (22687 left)
sdram_config=0x0062
sdram_refresh=0x0000
sdram_ncdl=0xff010a
sdram_init=0x010b

Looking at most units out there shows that the only value which differs is sdram_ncdl.

Here is all the different values I found:

sdram_ncdl=0xfd0009
sdram_ncdl=0xfe0008
sdram_ncdl=0xfe0009
sdram_ncdl=0xfe000a
sdram_ncdl=0xfe0107
sdram_ncdl=0xfe0108
sdram_ncdl=0xfe0109
sdram_ncdl=0xff0008
sdram_ncdl=0xff0107
sdram_ncdl=0xff0108
sdram_ncdl=0xff0109
sdram_ncdl=0xff010a
sdram_ncdl=0xff0208

What exactly does this value mean?

(Last edited by lc on 30 Mar 2007, 08:00)

Hey guys, I'm back. I've read all your posts and various attempts to fix the problem, sad to see that nobody seems to have come up with a real solution yet. I took another look at Sveasoft and thought that perhaps they've found a workaround and sent them an email regarding these crashes. Check out what they responded:

That seems to confirm what nbd is hinting at. nbd, what value should these sdram parameters have? Is it model specific? lc has a whole bunch of these, I checked on my assortment of 24 deployed WRT54GL's (all of which are v1.1 and are experiencing these issues) and found the following unique, sorted values

0xfd0008
0xfe0007
0xfe0008
0xfe0009
0xfe0108
0xfe0109
0xff0008
0xff0107
0xff0108
0xff0109

Similar to lc's values, but I got a few different ones in there too. Why the heck are they all different if I never changed them and the hardware is identical? What do they mean?

Btw, I thought I was only plagued by random reboots. Now I've confirmed several crashes too on my hardware, i.e. internal memory corruption without the unit rebooting itself, causing MUCH more grief because I need to go on site and power cycle the buggers myself :-( But it seems to contradict what others are finding here, I get very few crashes and mostly reboots on my WRT54GL's.

Edit: I've run nbd's script on one of my heavily used hotspots (keeping fingers crossed ;-) and it changed quite a few values:

Checking Linksys WRT54G* fixups...
Adding fixups for BCM5352E
nvram: pa0b0: '0x170c' -> '0x168b'
nvram: pa0b1: '0xfa24' -> '0xfabf'
nvram: pa0b2: '0xfe70' -> '0xfeaf'
nvram: pa0maxpwr: '0x48' -> '0x4e'

I did this 10 minutes ago and will have to sit and wait if it makes the reboots disappear...

(Last edited by gmayer on 9 Apr 2007, 23:37)

sdram_init determines the ram capacity
sdram_config sets various config parameters
sdram_ncdl is for timing

An sdram_ncdl value of 0 will cause it to recalculate the timing the next boot; nonzero values are timing information.

We already know that linksys shipped with horrible sdram settings on some boards and we already have startup scripts to correct these values (/etc/init.d/S05nvram). Not all of the "my router crashes" reports here are caused by the same issue, it's just the same symptom.

EDIT - did anyone mistakenly copy nvram settings from one router to another? this _WILL_ cause problems.

(Last edited by mbm on 9 Apr 2007, 23:44)

Hi mbm,

thanks for the explanation. What about the crashes that only occur when wireless radio is turned on? Is this an sdram issue?

Good to see a second developer here. Thanks for the info mbm, though I still don't understand why the sdram_ncdl timing values would be different for the same router, model and revision. Also why doesn't one just set it to zero to be safe?

Is the /etc/init.d/S05nvram you mentioned any different from nbd's nvram-fixup.sh? Cause the latter actually makes no difference on one of my production boxes, in fact it now seems to reboot more often than before (I've since reverted to my previous config of course), though it only touched the pa0b<n> and pa0maxpwr variables.

I do use standard configuration images that were created on one specific router and then applied to a whole lot of others (makes installation and configuration a hell of a lot easier), but scanning through them in a hex editor yields no reference to the sdram_* and pa0* parameters so I think this is unlikely to be the problem. Or am I mistaken?

Actually that may a problem with the power, turning on the wireless increases the draw on the power supply and may push the limits of what the power supply can provide. Try replacing the power adapter.