Dev builds brick my DIR-860 B1

Hi OpenWRT team,

Periodically I create my own builds from your git.
But my last good build is from 25.11.2018.

I tested with "make clean" but same issue, I tested with dev build from but same issue.

Router : DLink DIR-860L B1
CPU : MT7621 (ramips)

The last week has many changes over partition and ramips. Maybe this is the problem.

Sorry for my bad English !



What are the problems you are seeing?

(Also, builds off master or any other development branch are not "guaranteed" to be stable at any specific point in time, nor directly upgradable from previous versions.)


I use "master" branch.

The problem is : The router is dead and only orange led light is on.

The factory recovery procedure work.

Yes, I know this is dev branch but I use this branch more than 1 year and this is first time with big problem.

P.S.: Same problem with "Development Snapshot builds" on

At least in my personal experience, "dev" builds (including snapshots) "break" regularly in various ways and one has to be prepared with the appropriate recovery tools.

Looking at the commit logs can help in avoiding periods of time where there is active development going on either for the hardware/architecture of interest, or specific features. (I had some hair-pulling experiences this spring as changes were being made to netifd and hostapd.)

OK, my last working build is "OpenWrt SNAPSHOT r8567-be3e69d991".
I will wait for fix :slight_smile:

Thanks, Jeff!

If you can recover easily - and given that your problem seems to reproduce reliably, the easiest way to debug this would be git bisect over the OpenWrt repo. Considering that your last known good build is pretty recent, you should be done within 5-6 rebuilds, until you know for sure which exact commit breaks it for you - knowing (and reporting) that will allow fixing it easily.


Its very likely related to this: MT76x02 Kernel Panic

And possibly: Backport mac80211 compile error

I'm waiting for a fix myself.

No, I don't have kernel panic. My router is dead with new builds.

I think what @drbrains might have been hinting at is that one or both of those commits may have "broken" the build.

@slh suggesting using git bisect to locate the "first bad" commit is a good one, pone I have used myself several times. The manual for git bisect is pretty good, but basically you "start" with a known-bad commit, checkout another commit (that you already know is good), build it, test it, confirm that it's good, then mark it as "good" with git. The git system will then start checking out commits for you to test, being "smart" about it, so that you generally only have to check ~log2(number from bad to good) commits. You can find the "first bad" commit over 100 commits in about 7 tests or so.

There's a "worked example" of using git bisect at

It's probably my76 related, best (easiest) way would be to do build a firmware without mt76 at all for remove it from the equation.

Fixed !;a=commit;h=ed000fcaf2cfa22bb558ed11c8a15d239240020b

Thanks! :slight_smile:

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.