Reply
Emerging Member
Posts: 98
Registered: ‎02-12-2014
Kudos: 11
Solutions: 3

Dead USG

Good morning all.

This morning when I got to work I noticed that my network was down (VoIP phones, computers, AP's, UniFi Video cameras and so on.

I looked things over and quickly found that the USG was down.

I could not ping it, and upon physical inspection found that the "lighted square" on the front was not lit, but the LAN and WAN port LED's were on.

I cycled the power and gave it a few min's to come back up but it could not be detected by the controller (running on my PC w/statically assigned IP).

I attempted to do a hard reset on the USG, following UBNT-Jamie's video, but the VoIP led did not behave as explained in the video. In fact it made no indication that I had the reset button held down.

I left the unit unplugged for a while and plugged it back in with nothing else connected. This time it booted up and gave me the flashing "lighted square". I used my laptop (set for DHCP, and then statically assigned as 192.168.1.100) to attempt to ping the gateway in its default IP state, and also tried the UniFi discovery utility in an attempt to find it. I tried configuring my laptop to the default range (192.168.1.1) as well as its last working setting with no luck.

I can not seem to get it back or even acces it no matter what I have tried so far.

 

Any ideas? Or do you think it may have quit for good?

Regular Member
Posts: 697
Registered: ‎11-29-2012
Kudos: 202
Solutions: 36

Re: Dead USG

It's time to connect the serial console cable and see what it has to say.

Emerging Member
Posts: 98
Registered: ‎02-12-2014
Kudos: 11
Solutions: 3

Re: Dead USG

I have connected a console cable and am using hyperterminal connected using, 9600/8/none/1/none 

Do I need to type anything to get something to display?

I am not terrible handy with a console so a little help from here would be amazing.

Thanks

Regular Member
Posts: 697
Registered: ‎11-29-2012
Kudos: 202
Solutions: 36

Re: Dead USG

From the guide: http://dl.ubnt.com/guides/UniFi/USG_QSG.pdf

• Baud rate 115200

• Data bits 8

• Parity NONE

• Stop bits 1

• Flow control NONE

Once you initiate the connection with the correct baud rate you should see something if the unit is alive.
If it's already booted you may have to press ENTER to see something.

Emerging Member
Posts: 98
Registered: ‎02-12-2014
Kudos: 11
Solutions: 3

Re: Dead USG

 Thank you dison4linux.

I set the properties for the hyperterminal session as you suggested, and rebooted the USG.

Here is what I had after 10mins connected:

Looking for valid bootloader image....
Jumping to start of image at address 0xbfc80000


U-Boot 1.1.1 (UBNT Build ID: 4674499-gfa58f5d) (Build time: Jun  9 2014 - 14:38:
01)

BIST check passed.
UBNT_E120 r1:0, r2:16, f:8/135, serial #: 0418D6830580
MPR 13-02044-16
Core clock: 500 MHz, DDR clock: 266 MHz (532 Mhz data rate)
DRAM:  512 MB
Clearing DRAM....... done
Flash:  8 MB
Net:   octeth0, octeth1, octeth2

USB:   (port 0) scanning bus for devices... 1 USB Devices found
       scanning bus for storage devices...
  Device 0: Vendor:          Prod.: USB DISK 2.0     Rev: PMAP
            Type: Removable Hard Disk
            Capacity: 3824.0 MB = 3.7 GB (7831552 x 512)
 0
reading vmlinux.64
............................

5683792 bytes read
argv[2]: coremask=0x3
argv[3]: root=/dev/sda2
argv[4]: rootdelay=15
argv[5]: rw
argv[6]: rootsqimg=squashfs.img
argv[7]: rootsqwdir=w
argv[8]: mtdparts=phys_mapped_flash:512k(boot0),512k(boot1),64k@1024k(eeprom)
ELF file is 64 bit
Allocating memory for ELF segment: addr: 0xffffffff80100000 (adjusted to: 0x1000
00), size 0x59c5f0
Allocated memory for ELF segment: addr: 0xffffffff80100000, size 0x59c5f0
Processing PHDR 0
  Loading 567400 bytes at ffffffff80100000
  Clearing 351f0 bytes at ffffffff80667400
## Loading Linux kernel with entry point: 0xffffffff804585b0 ...
Bootloader: Done loading app on coremask: 0x3
Linux version 3.4.27-UBNT (ancheng@ubnt-builder2) (gcc version 4.7.0 (Cavium Inc
. Version: SDK_3_0_0 build 16) ) #1 SMP Tue Aug 12 17:54:01 PDT 2014
CVMSEG size: 2 cache lines (256 bytes)
Cavium Inc. SDK-3.0
bootconsole [early0] enabled
CPU revision is: 000d0601 (Cavium Octeon+)
Checking for the multiply/shift bug... no.
Checking for the daddiu bug... no.
Determined physical RAM map:
 memory: 0000000007800000 @ 0000000000700000 (usable)
 memory: 0000000007c00000 @ 0000000008200000 (usable)
 memory: 000000000fc00000 @ 0000000410000000 (usable)
 memory: 0000000000047000 @ 0000000000629000 (usable after init)
Wasting 88312 bytes for tracking 1577 unused pages
Placing 0MB software IO TLB between 8000000001707000 - 8000000001747000
software IO TLB at phys 0x1707000 - 0x1747000
Zone PFN ranges:
  DMA32    0x00000629 -> 0x000f0000
  Normal   0x000f0000 -> 0x0041fc00
Movable zone start PFN for each node
Early memory PFN ranges
    0: 0x00000629 -> 0x00000670
    0: 0x00000700 -> 0x00007f00
    0: 0x00008200 -> 0x0000fe00
    0: 0x00410000 -> 0x0041fc00
Cavium Hotplug: Available coremask 0x0
Primary instruction cache 32kB, virtually tagged, 4 way, 64 sets, linesize 128 b
ytes.
Primary data cache 16kB, 64-way, 2 sets, linesize 128 bytes.
Secondary unified cache 128kB, 8-way, 128 sets, linesize 128 bytes.
PERCPU: Embedded 10 pages/cpu @8000000001784000 s9216 r8192 d23552 u40960
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 67946
Kernel command line:  bootoctlinux $loadaddr coremask=0x3 root=/dev/sda2 rootdel
ay=15 rw rootsqimg=squashfs.img rootsqwdir=w mtdparts=phys_mapped_flash:512k(boo
t0),512k(boot1),64k@1024k(eeprom) console=ttyS0,115200
PID hash table entries: 2048 (order: 2, 16384 bytes)
Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
Inode-cache hash table entries: 32768 (order: 6, 262144 bytes)
Memory: 499340k/508188k available (3469k kernel code, 8848k reserved, 1812k data
, 284k init, 0k highmem)
Hierarchical RCU implementation.
NR_IRQS:256
Calibrating delay loop (skipped) preset value.. 1000.00 BogoMIPS (lpj=5000000)
pid_max: default: 32768 minimum: 301
Security Framework initialized
Mount-cache hash table entries: 256
Checking for the daddi bug... no.
SMP: Booting CPU01 (CoreId  1)...
CPU revision is: 000d0601 (Cavium Octeon+)
Brought up 2 CPUs
NET: Registered protocol family 16
bio: create slab <bio-0> at 0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Switching to clocksource OCTEON_CVMCOUNT
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 3, 32768 bytes)
TCP established hash table entries: 16384 (order: 6, 262144 bytes)
TCP bind hash table entries: 16384 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP: reno registered
UDP hash table entries: 256 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
NET: Registered protocol family 1
ERROR: octeon_pci_console_setup0 failed.
/proc/octeon_perf: Octeon performance counter interface loaded
squashfs: version 4.0 (2009/01/31) Phillip Lougher
Registering unionfs 2.5.11 (for 3.4)
msgmni has been set to 975
io scheduler noop registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 6 ports, IRQ sharing disabled
loop: module loaded
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
OcteonUSB 16f0010000000.usbc: Octeon Host Controller
OcteonUSB 16f0010000000.usbc: new USB bus registered, assigned bus number 1
OcteonUSB 16f0010000000.usbc: irq 56, io mem 0x00000000
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
OcteonUSB: Registered HCD for port 0 on irq 56
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usbcore: registered new interface driver libusual
octeon_wdt: Initial granularity 5 Sec
TCP: cubic registered
NET: Registered protocol family 17
NET: Registered protocol family 15
L2 lock: TLB refill 256 bytes
L2 lock: General exception 128 bytes
L2 lock: low-level interrupt 128 bytes
L2 lock: interrupt 640 bytes
L2 lock: memcpy 1152 bytes
1180000000800.serial: ttyS0 at MMIO 0x1180000000800 (irq = 34) is a OCTEON
console [ttyS0] enabled, bootconsole disabled
console [ttyS0] enabled, bootconsole disabled
1180000000c00.serial: ttyS1 at MMIO 0x1180000000c00 (irq = 35) is a OCTEON
Bootbus flash: Setting flash for 8MB flash at 0x1f400000
phys_mapped_flash: Found 1 x16 devices at 0x0 in 8-bit bank. Manufacturer ID 0x0
000c2 Chip ID 0x0000c9
Amd/Fujitsu Extended Query Table at 0x0040
  Amd/Fujitsu Extended Query version 1.1.
phys_mapped_flash: Swapping erase regions for top-boot CFI table.
number of CFI chips: 1
3 cmdlinepart partitions found on MTD device phys_mapped_flash
Creating 3 MTD partitions on "phys_mapped_flash":
0x000000000000-0x000000080000 : "boot0"
0x000000080000-0x000000100000 : "boot1"
0x000000100000-0x000000110000 : "eeprom"
Waiting 15sec before mounting root device...
usb 1-1: new high-speed USB device number 2 using OcteonUSB
scsi0 : usb-storage 1-1:1.0
scsi 0:0:0:0: Direct-Access              USB DISK 2.0     PMAP PQ: 0 ANSI: 6
sd 0:0:0:0: [sda] 7831552 512-byte logical blocks: (4.00 GB/3.73 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] No Caching mode page present
sd 0:0:0:0: [sda] Assuming drive cache: write through
sd 0:0:0:0: [sda] No Caching mode page present
sd 0:0:0:0: [sda] Assuming drive cache: write through
 sda: sda1 sda2 sda3
sd 0:0:0:0: [sda] No Caching mode page present
sd 0:0:0:0: [sda] Assuming drive cache: write through
sd 0:0:0:0: [sda] Attached SCSI removable disk
INFO: rcu_sched self-detected stall on CPU { 0}  (t=6000 jiffies)
Call Trace:
[<ffffffff8045b0cc>] dump_stack+0x8/0x34
[<ffffffff801abb8c>] __rcu_pending+0x1d4/0x548
[<ffffffff801acaf8>] rcu_check_callbacks+0xa0/0x150
[<ffffffff80168ee0>] update_process_times+0x48/0x68
[<ffffffff80195540>] tick_sched_timer+0x70/0x190
[<ffffffff8017deb4>] __run_hrtimer.isra.20+0x64/0xf8
[<ffffffff8017e4c8>] hrtimer_interrupt+0x130/0x308
[<ffffffff8013fff4>] c0_compare_interrupt+0x5c/0x88
[<ffffffff801a3f98>] handle_irq_event_percpu+0x88/0x230
[<ffffffff801a7cd4>] handle_percpu_irq+0x8c/0xc0
[<ffffffff801a35a8>] generic_handle_irq+0x38/0x50
[<ffffffff8013b828>] do_IRQ+0x18/0x30
[<ffffffff801047ec>] plat_irq_dispatch+0x64/0xe8
[<ffffffff80139b4c>] ret_from_irq+0x0/0x4
[<ffffffff801ae790>] find_get_page+0x30/0xc0
[<ffffffff8021a0c4>] __find_get_block_slow+0x4c/0x198
[<ffffffff8021ce88>] __find_get_block+0x188/0x2b8
[<ffffffff8021cff4>] __getblk+0x3c/0x320
[<ffffffff80280240>] jread+0x70/0x268
[<ffffffff802804c4>] do_one_pass+0x8c/0x518
[<ffffffff802809bc>] journal_recover+0x6c/0x120
[<ffffffff80283fec>] journal_load+0x7c/0xf0
[<ffffffff80268398>] ext3_fill_super+0xfb8/0x1930
[<ffffffff801ee924>] mount_bdev+0x1fc/0x240
[<ffffffff801ef6f8>] mount_fs+0x50/0x1f8
[<ffffffff8020abe0>] vfs_kern_mount+0x58/0xe8
[<ffffffff8020b4dc>] do_kern_mount+0x54/0x118
[<ffffffff8020d150>] do_mount+0x3a8/0x810
[<ffffffff8020d750>] SyS_mount+0x98/0xf0
[<ffffffff80629c44>] do_mount_squash_image.constprop.4+0x64/0x464
[<ffffffff8062a178>] mount_block_root+0x134/0x314
[<ffffffff8062a510>] prepare_namespace+0x14c/0x180
[<ffffffff80629a78>] kernel_init+0x1d8/0x1e0
[<ffffffff8013b978>] kernel_thread_helper+0x10/0x18

INFO: rcu_sched self-detected stall on CPU { 0}  (t=24003 jiffies)
Call Trace:
[<ffffffff8045b0cc>] dump_stack+0x8/0x34
[<ffffffff801abb8c>] __rcu_pending+0x1d4/0x548
[<ffffffff801acaf8>] rcu_check_callbacks+0xa0/0x150
[<ffffffff80168ee0>] update_process_times+0x48/0x68
[<ffffffff80195540>] tick_sched_timer+0x70/0x190
[<ffffffff8017deb4>] __run_hrtimer.isra.20+0x64/0xf8
[<ffffffff8017e4c8>] hrtimer_interrupt+0x130/0x308
[<ffffffff8013fff4>] c0_compare_interrupt+0x5c/0x88
[<ffffffff801a3f98>] handle_irq_event_percpu+0x88/0x230
[<ffffffff801a7cd4>] handle_percpu_irq+0x8c/0xc0
[<ffffffff801a35a8>] generic_handle_irq+0x38/0x50
[<ffffffff8013b828>] do_IRQ+0x18/0x30
[<ffffffff801047ec>] plat_irq_dispatch+0x64/0xe8
[<ffffffff80139b4c>] ret_from_irq+0x0/0x4
[<ffffffff802e15e8>] radix_tree_lookup_element+0x68/0xa8
[<ffffffff801ae784>] find_get_page+0x24/0xc0
[<ffffffff8021a0c4>] __find_get_block_slow+0x4c/0x198
[<ffffffff8021ce88>] __find_get_block+0x188/0x2b8
[<ffffffff8021cff4>] __getblk+0x3c/0x320
[<ffffffff80280240>] jread+0x70/0x268
[<ffffffff802804c4>] do_one_pass+0x8c/0x518
[<ffffffff802809bc>] journal_recover+0x6c/0x120
[<ffffffff80283fec>] journal_load+0x7c/0xf0
[<ffffffff80268398>] ext3_fill_super+0xfb8/0x1930
[<ffffffff801ee924>] mount_bdev+0x1fc/0x240
[<ffffffff801ef6f8>] mount_fs+0x50/0x1f8
[<ffffffff8020abe0>] vfs_kern_mount+0x58/0xe8
[<ffffffff8020b4dc>] do_kern_mount+0x54/0x118
[<ffffffff8020d150>] do_mount+0x3a8/0x810
[<ffffffff8020d750>] SyS_mount+0x98/0xf0
[<ffffffff80629c44>] do_mount_squash_image.constprop.4+0x64/0x464
[<ffffffff8062a178>] mount_block_root+0x134/0x314
[<ffffffff8062a510>] prepare_namespace+0x14c/0x180
[<ffffffff80629a78>] kernel_init+0x1d8/0x1e0
[<ffffffff8013b978>] kernel_thread_helper+0x10/0x18

Not sure if there is anything usefull there, but that is what I got.

At this time, the "lighted square" is not even lighting up anymore...

 

Regular Member
Posts: 697
Registered: ‎11-29-2012
Kudos: 202
Solutions: 36

Re: Dead USG

I'm not sure, but that kinda looks like the USB storage device is corrupted/failed.

Maybe someone from UBNT can confirm.

I'm not sure if there is any method of TFTP recovery for this model.

Are you still within RMA period? (Assuming so since these haven't been available for that long).

Emerging Member
Posts: 98
Registered: ‎02-12-2014
Kudos: 11
Solutions: 3

Re: Dead USG

Yes, I can RMA the thing back to my distrubiter but was hoping there was something I can do to fix it.

If someone does not have any ideas I guess I will have to do that.

I had my old Linksys RV042 router still sitting on the shelf so I plugged it back in until I get this fixed.

 

Unfortunate, I make a habit of using things at my office for some time before selling to clients.

I hope there is not a high failure rate with these.

 

Thank's for looking.

Regular Member
Posts: 697
Registered: ‎11-29-2012
Kudos: 202
Solutions: 36

Re: Dead USG

Assuming the USGs use the same USB device for storage as the ERLs then yes there is some history of failures.  I'm not sure what the rate/percentage is but its more than 1 Man Happy

Again, we're not even sure that's what's wrong with yours.

And yes there may be a way to fix it if both:
1) It's only a filesystem corruption issue
2) There's a TFTP recovery method avaialable

New Member
Posts: 3
Registered: ‎04-25-2016

Re: Dead USG

[ Edited ]

2 years later and I have the same problem. Is there an USG image available for download so I can put that image on a new 4Gb USB drive?

Highlighted
Ubiquiti Employee
Posts: 5,012
Registered: ‎08-08-2016
Kudos: 5421
Solutions: 346

Re: Dead USG


@simmetje wrote:

2 years later and I have the same problem. Is there an USG image available for download so I can put that image on a new 4Gb USB drive?


Yes, here. 

https://dl.ubnt-ut.com/cmb/USG-4_2_0-shipped.img.bz2

 

bunzip and dd that, or if on Windows, win32diskimager is a good option. 

New Member
Posts: 10
Registered: ‎10-01-2014
Kudos: 1

Re: Dead USG


@UBNT-cmb wrote:

@simmetje wrote:

2 years later and I have the same problem. Is there an USG image available for download so I can put that image on a new 4Gb USB drive?


Yes, here. 

https://dl.ubnt-ut.com/cmb/USG-4_2_0-shipped.img.bz2

 

bunzip and dd that, or if on Windows, win32diskimager is a good option. 


Even later still, but could you possibly update with a file hash so people can verify their downloads?

Also, would you ever consider hosting recovery images like this on the official download pages for your products?

Reply