B3 dies without errors

[DanielM]

Hi Ubi.

Agreed.
I think it is dead (in my case anyway), as it doesn't even respond to the power button.
But at least I'll find out if the cron job even executes...

Agreed on all points.

/Daniel

[Clive]

Just thinking of another possible reason as my Bubba 1 did exactly the same and after 2 years uptime, suddenly hung at least once a month and need it's power plug removed to re-cycle. Nothing was ever listed in any of the logs prior to the hanging.

The only thing that had changed was my router was upgraded to a Thomson TG784 (Bredbansbolaget i Sverige)and I initially had a few problem with it, apparently it did not fully support fixed IP addresses on the WAN and according to Bredbandsbolget "there are a few known issues with this router"...

Are any of the others experiencing these problems with B2/B3 using a similar router, or same ISP (I note that some of you are in Sweden). I was wondering if BB were sending some incorrect packets towards my Bubba which it disagreed with ?

[Cheeseboy]

Hi Clive,

No, my B3 acts as router and plugs straight into the fibre box, nothing in-between.
My ISP Bahnhof.

Cheers,

Cheeseboy

[DanielM]

No, my B3 acts as router and plugs straight into the fibre box, nothing in-between.
My ISP Bahnhof.

Exactly same setup. Fibre converter straight into B3 which acts as router+wireless ap+everything else.

Never experienced this with my B1 (which of course didn't act router though, it was behind a Netgear WNR2000 router).

/Daniel

[Hammer]

Have the same problem from time to time.

Tried to update the OS, but it timed out at 97.x%, just retries the connection.
Now I can't access the B3 web interface at all, but as evidenced by this post, can still surf.

Is there a solution for this disconnect problem?

[Cheeseboy]

OK, it happened again.
The cron script I prepared did not execute, so I can conclude that the b3 just died.

Again I see garbage written to the syslog at the time the system died:

Code: Select all

Dec  4 00:00:01 b3 dnsmasq-dhcp[1662]: DHCPREQUEST(br0) 192.168.10.59 00:25:d3:86:32:ea 
Dec  4 00:00:01 b3 dnsmasq-dhcp[1662]: DHCPACK(br0) 192.168.10.59 00:25:d3:86:32:ea muttan
Dec  4 00:00:01 b3 /USR/SBIN/CRON[21785]: (root) CMD (test -x /usr/bin/php && /usr/bin/php /usr/share/horde3/scripts/alarms.php > /dev/null 2>&1)
Dec  4 00:00:01 b3 /USR/SBIN/CRON[21786]: (root) CMD (test -x /usr/lib/web-admin/notify-dispatcher.pl && /usr/lib/web-admin/notify-dispatcher.pl)
2a4ce729460e7553a0.7.9.4python-foomatic0.7.9.42.6pconf-detecta8f225a7481782ce603af53512d3310cprintconf0.7.9.40.50.7.9.4python-cups41a86ede619f7221746f8aa1eedec8e60.7.9.40.6.11python-ipy0.70.74e585cdff3d43de4ec1ffe45b9bb8ffafop-docDec  4 01:11:32 b3 kernel: imklog 4.6.4, log source = /proc/kmsg started.
Dec  4 01:11:32 b3 rsyslogd: [origin software="rsyslogd" swVersion="4.6.4" x-pid="1371" x-info="http://www.rsyslog.com"] (re)start
Dec  4 01:11:32 b3 kernel: [    0.000000] Linux version 2.6.35.4 (tor@tor-desktop) (gcc version 4.3.4 (crosstool-NG-1.7.1-excito-201007) ) #5 Tue Sep 7 16:06:15 CEST 2010

I think we (the community) has done all we can, so I'm going to report it to Excito.

[DanielM]

I think we (the community) has done all we can, so I'm going to report it to Excito.

Rest assured Excito already knows. I'm sure they'll be thankful for all information they get about it though.

I'm thinking of completely disabling wifi on my B3 and plug in my old Netgear router (used as pure AP) and see if that helps...

/Daniel

[Ubi]

My B3+wifi is connected through the LAN port where a thomson 784 is doing nat and adsl and wifi, and my machine has never crashed, despite that wifi is enabled. So maybe the issue is in the routing between LAN and WAN and not so much the wifi per se

[DanielM]

My B3+wifi is connected through the LAN port where a thomson 784 is doing nat and adsl and wifi, and my machine has never crashed, despite that wifi is enabled. So maybe the issue is in the routing between LAN and WAN and not so much the wifi per se

That is interesting. So what you're saying is that you haven't experienced any of the problems described above? Can't really see though how some routing could crash the machine. Is routing in any way very heavy to do?

/Daniel

[Ubi]

No, my b3 been doing great, but I should not that I'm not using the wireless much. It's turned on, but I never really connect to it (as I connect to the adsl router).

[Asad]

I have got a new unit but the problem is still ongoing. After manual restart I see this in the log:
The garbage text does not appear each time. I have contacted the support for additional troubleshooting.

Dec 4 14:23:23 b3 kernel: [ 315.526721] wlan0: no IPv6 routers present
�h�� ������� ��oC �[C ��~���h�� ���C7$� ��pC �!C ��~���h�� ��I7$� ��qC �*C ��~���h�� ������ ��rC �/: ��~���h�� �������Xd��sC �n+ ��~���h�� �������k ��tC ��A ��~���h�� �����������uC ������~���Dec 4 14:31:14 b3 kernel: [ 0.000000] On node 0 totalpages: 131072
Dec 4 14:31:14 b3 kernel: [ 0.000000] free_area_init_node: node 0, pgdat c0466ee4, node_mem_map c0488000
Dec 4 14:31:14 b3 kernel: [ 0.000000] Normal zone: 1024 pages used for memmap
Dec 4 14:31:14 b3 kernel: [ 0.000000] Normal zone: 0 pages reserved
Dec 4 14:31:14 b3 kernel: [ 0.000000] Normal zone: 130048 pages, LIFO batch:31
Dec 4 14:31:14 b3 kernel: [ 0.233843] initial MPP regs: 01112222 43303311 33330044 33003333 00000033 00000000 00000000
Dec 4 14:31:14 b3 kernel: [ 0.233871] final MPP regs: 11112222 43303311 33330044 33003333 00000033 00000000 00000000
Dec 4 14:31:14 b3 kernel: [ 0.235386] pci 0000:00:00.0: reg 10: [mem 0xd0000000-0xd00fffff 64bit pref]
Dec 4 14:31:14 b3 kernel: [ 0.235402] pci 0000:00:00.0: reg 18: [mem 0x00000000-0x1fffffff]
Dec 4 14:31:14 b3 kernel: [ 0.235432] pci 0000:00:00.0: supports D1 D2
Dec 4 14:31:14 b3 kernel: [ 0.235482] pci 0000:00:01.0: reg 10: [mem 0x00000000-0x0000ffff 64bit]
Dec 4 14:31:14 b3 kernel: [ 0.235544] pci 0000:00:01.0: supports D1
Dec 4 14:31:14 b3 kernel: [ 0.235553] pci 0000:00:01.0: PME# supported from D0 D1 D3hot
Dec 4 14:31:14 b3 kernel: [ 0.235565] pci 0000:00:01.0: PME# disabled
Dec 4 14:31:14 b3 kernel: [ 0.245013] libata version 3.00 loaded.
Dec 4 14:31:14 b3 kernel: [ 0.249544] PCI: CLS 32 bytes, default 32
Dec 4 14:31:14 b3 kernel: [ 1.110442] Gating clock of unused units
Dec 4 14:31:14 b3 kernel: [ 1.110452] before: 0x00dfc3fd
Dec 4 14:31:14 b3 kernel: [ 1.110458] after: 0x00cfc1cd
Dec 4 14:31:14 b3 kernel: [ 1.359288] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
Dec 4 14:31:14 b3 kernel: [ 2.043944] ext3_orphan_cleanup: deleting unreferenced inode 592532
Dec 4 14:31:14 b3 kernel: [ 2.044040] ext3_orphan_cleanup: deleting unreferenced inode 592531
Dec 4 14:31:14 b3 kernel: [ 2.044080] ext3_orphan_cleanup: deleting unreferenced inode 248298
Dec 4 14:31:14 b3 kernel: [ 2.044109] ext3_orphan_cleanup: deleting unreferenced inode 248297
Dec 4 14:31:14 b3 kernel: [ 2.044133] ext3_orphan_cleanup: deleting unreferenced inode 248295
Dec 4 14:31:14 b3 kernel: [ 2.044156] ext3_orphan_cleanup: deleting unreferenced inode 248294
Dec 4 14:31:14 b3 kernel: [ 2.044179] ext3_orphan_cleanup: deleting unreferenced inode 248293
Dec 4 14:31:14 b3 kernel: [ 2.044201] ext3_orphan_cleanup: deleting unreferenced inode 248289
Dec 4 14:31:14 b3 kernel: [ 2.044226] ext3_orphan_cleanup: deleting unreferenced inode 248287
Dec 4 14:31:14 b3 kernel: [ 2.044253] ext3_orphan_cleanup: deleting unreferenced inode 598044
Dec 4 14:31:14 b3 kernel: [ 2.044280] ext3_orphan_cleanup: deleting unreferenced inode 248286
Dec 4 14:31:14 b3 kernel: [ 2.044303] ext3_orphan_cleanup: deleting unreferenced inode 248278
Dec 4 14:31:14 b3 kernel: [ 5.343576] phy0: Selected rate control algorithm 'ath9k_rate_control'

[Cheeseboy]

It seems an instrumentation is in order.
Perhaps if Excito could release a kernel compiled with more debug options enabled, us users could let it it fail and collect more data for troubleshooting.

Sending replacement hardware to starlight doesn't seem to have cut it.
I appreciate that Excito did it though. One less possible cause of the problem has been eliminated.
EDIT: Well, unless the whole batch is flawed with faulty memory units or the like...

/Cheeseboy

[rasmus]

So after reading this thread i can say that i have somewhat of the same problem.

Last night, after running just fine for almost 10 days, suddenly my B3 died. No connection to the internet og access to the B3 using WLAN og LAN, i noticed that my desktop connected using the LAN cable got an ip called 169.xyz.xyz.xxxx instead of the normal 192.168.10.xyz (per default settings in the B3 network). When trying to access the b3.local using my desktop i just got the "redirecting" and then it said "page cant be found"-error message from my browser.

I'm not sure if the connection error is related to the fact that i have changed the htaccess for the entire /web/ so its only accesaisble from 192.168.10.xyz....

Then a few minutes ago, my connection to the internet died again - this time the B3 were still running and connection through SSH / Web was still fine, i got it back on the internet using ifdown/ifup.

Im not really sure what to look for in the logs, but in the /var/logs/messages i do see something like this a few times (dont know if i should worry, since i dont know much about linux ):

Code: Select all

Jan  9 12:34:37 b3 kernel: [821891.439829] SLUB: Unable to allocate memory on node -1 (gfp=0x20)
Jan  9 12:34:37 b3 kernel: [821891.445982]   cache: kmalloc-8192, object size: 8192, buffer size: 8192, default order: 3, min order: 1
Jan  9 12:34:37 b3 kernel: [821891.455425]   node 0: slabs: 169, objs: 670, free: 0
Jan  9 12:34:37 b3 kernel: [821891.460556] swapper: page allocation failure. order:1, mode:0x4020

I have an almost clean install, ive installed vnstat and rtorrent, and i was playing around with rtorrent yesterday downloading some stuff trying to test the capacity of my connection, and thous i suspect rtorrent of being a trouble maker - using htop/top i see that rtorrent from time to time is using "alot" of cpu/mem (50%+ isnt uncommon) while hashing torrents but i guess that could be expected...

I have just added the "vm.min_free_kbytes = 8192" line to the sysctl.conf, dont know if that will help

Anyway, dont know if any of this is usefull or anything - just thought i would share my problems with the "group"

//Rasmus

[Ubi]

Code: Select all

Jan  9 12:34:37 b3 kernel: [821891.439829] SLUB: Unable to allocate memory on node -1 (gfp=0x20)
Jan  9 12:34:37 b3 kernel: [821891.445982]   cache: kmalloc-8192, object size: 8192, buffer size: 8192, default order: 3, min order: 1
Jan  9 12:34:37 b3 kernel: [821891.455425]   node 0: slabs: 169, objs: 670, free: 0
Jan  9 12:34:37 b3 kernel: [821891.460556] swapper: page allocation failure. order:1, mode:0x4020

This means your programs need more memory than they can get.
Please give me the output of:

Code: Select all

 free -m

next time you experience this problem.

I wouldn't be surprised if an increase in swap size alleviates your problems, but I'm not convinced you're experiencing the same issues as others.

[Cheeseboy]

Hi,

I must add that it actually sounds like a different error than the one this thread was originally started for:
A total crash/indefinite hang of the entire system with _NO_ errors in the logs.
The system never recovers and there are no errors, hence the title of the thread.

If I where you, I would post it in a new thread.
There is another thread related to memory allocation:
http://forum.excito.net/viewtopic.php?p=12592#p11927
But the errors look different than yours.

I also know that if the system suddenly runs out of memory, it can manifest itself in any number of ways, but I think it would be good to report every different behaviour in a new thread, and also directly to Excito for their expert judgement. It will make it easier for others that have the same issue you do to isolate the issue from all the others that have somehow ended up in here.

Just my 2 cents.

Cheers,

Cheeseboy