Firebox Marvel ports locking up (CORE-E SERIES)
-
3 days, 12 hours and still chugging along.
-
Maybe the hardware is just finally giving up the ghost?
https://forum.pfsense.org/index.php?topic=101920.0 -
Maybe the hardware is just finally giving up the ghost?
https://forum.pfsense.org/index.php?topic=101920.0I don't believe this is the case, the logs show nothing like that and this has only started since going onto 2.2.3. It is also across multiple systems, mine being the box listed below, the other on a PC system with an intel chipset card. Mine is still up and running and appears to be stable, but saying that, it has gone as long as 15 days if I remember correctly.
Thanks for the link anyway.
-
It crapped itself this afternoon, twice in 5 minutes. Kinda weird it does this, running great for 6 days 10 hours or so.
-
If anyone is following this thread, I would like to say I have scrapped the FireBox project, too much down time from the ports dropping out. I have replaced it with another box with a lot better specs on the CPU and Memory…. Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz 4 CPUs: 1 package(s) x 4 core(s).
This thing is pretty sweet compared to the FireBox Celeron CPU.. lol
Take care all, see you in the next thread.
-
Im running a Watchguard x-550e box with donated 4 port switch from a 1250 at a site and have absolutely no issues what so ever with it. (Now that Ive opened my mouth though…)
13 days uptime right now and only since the power outage that hit the area. Otherwise it had been up since 2.2.5 release day. This box see's more than 40GB a day of transfer due to all the Netflix en such that goes on in the house there.
This is on the SK interfaces.
1.82Gb per hour average.
43.65Gb a day average.
23 active devices on the network right now. :o Big house. Lots of people.
-
Can anyone confirm that this is an issue only with the SK interfaces or are both SK and MSK interfaces affected?
-
I had massive problems with my sk interfaces (I don't have the msk interfaces, because it is an x550e). A workaround is, that the interfaces are now running on 100baseTX and are stable now.
-
Im running a 550-e at gigabit with no issues. Makes me wonder what the difference is between what Ive done and what I maybe haven't done.
Are you guys running the interface LED "fix" on your models?
-
Yes, I have this fix installed. Do you think that this might cause the behaviour?
-
Yes, I have this fix installed. Do you think that this might cause the behaviour?
I just checked to see if my box still had the mod as Its 30 miles away being used by friends. It does so Id say that it seems to make no difference. I am running a faster 533fsb 2.2 Intel(R) Pentium(R) M processor 2.26GHz on this guy with 2GB of ram. Clue? Full install on HD but that shouldn't matter.
$ dmesg|grep LED mskc0: <marvell yukon="" 88e8053="" gigabit="" ethernet="" (led="" mod="" 2.2)="">port 0x8000-0x80ff mem 0xd0020000-0xd0023fff irq 16 at device 0.0 on pci1 mskc1: <marvell yukon="" 88e8053="" gigabit="" ethernet="" (led="" mod="" 2.2)="">port 0x9000-0x90ff mem 0xd0120000-0xd0123fff irq 17 at device 0.0 on pci2 mskc2: <marvell yukon="" 88e8053="" gigabit="" ethernet="" (led="" mod="" 2.2)="">port 0xa000-0xa0ff mem 0xd0220000-0xd0223fff irq 18 at device 0.0 on pci3 mskc3: <marvell yukon="" 88e8053="" gigabit="" ethernet="" (led="" mod="" 2.2)="">port 0xb000-0xb0ff mem 0xd0320000-0xd0323fff irq 19 at device 0.0 on pci4 skc0: <marvell gigabit="" ethernet="" (led="" mod="" 2.2)="">port 0xc000-0xc0ff mem 0xd042c000-0xd042ffff irq 16 at device 0.0 on pci5 skc1: <marvell gigabit="" ethernet="" (led="" mod="" 2.2)="">port 0xc400-0xc4ff mem 0xd0420000-0xd0423fff irq 17 at device 1.0 on pci5 skc2: <marvell gigabit="" ethernet="" (led="" mod="" 2.2)="">port 0xc800-0xc8ff mem 0xd0424000-0xd0427fff irq 18 at device 2.0 on pci5 skc3: <marvell gigabit="" ethernet="" (led="" mod="" 2.2)="">port 0xcc00-0xccff mem 0xd0428000-0xd042bfff irq 19 at device 3.0 on pci5</marvell></marvell></marvell></marvell></marvell></marvell></marvell></marvell>
