Menu
▾
▴
astlinux-users — AstLinux Users Mailing List
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
(20) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(91) |
Feb
(111) |
Mar
(226) |
Apr
(65) |
May
(197) |
Jun
(202) |
Jul
(92) |
Aug
(87) |
Sep
(120) |
Oct
(133) |
Nov
(89) |
Dec
(155) |
| 2008 |
Jan
(251) |
Feb
(136) |
Mar
(174) |
Apr
(149) |
May
(56) |
Jun
(32) |
Jul
(36) |
Aug
(171) |
Sep
(245) |
Oct
(244) |
Nov
(218) |
Dec
(272) |
| 2009 |
Jan
(113) |
Feb
(119) |
Mar
(192) |
Apr
(117) |
May
(93) |
Jun
(46) |
Jul
(80) |
Aug
(54) |
Sep
(109) |
Oct
(70) |
Nov
(145) |
Dec
(110) |
| 2010 |
Jan
(137) |
Feb
(87) |
Mar
(45) |
Apr
(157) |
May
(58) |
Jun
(99) |
Jul
(188) |
Aug
(136) |
Sep
(101) |
Oct
(100) |
Nov
(61) |
Dec
(60) |
| 2011 |
Jan
(84) |
Feb
(43) |
Mar
(70) |
Apr
(17) |
May
(69) |
Jun
(28) |
Jul
(43) |
Aug
(21) |
Sep
(151) |
Oct
(120) |
Nov
(84) |
Dec
(101) |
| 2012 |
Jan
(119) |
Feb
(82) |
Mar
(70) |
Apr
(115) |
May
(66) |
Jun
(131) |
Jul
(70) |
Aug
(65) |
Sep
(66) |
Oct
(86) |
Nov
(197) |
Dec
(81) |
| 2013 |
Jan
(65) |
Feb
(48) |
Mar
(32) |
Apr
(68) |
May
(98) |
Jun
(59) |
Jul
(41) |
Aug
(52) |
Sep
(42) |
Oct
(37) |
Nov
(10) |
Dec
(27) |
| 2014 |
Jan
(61) |
Feb
(34) |
Mar
(30) |
Apr
(52) |
May
(45) |
Jun
(40) |
Jul
(28) |
Aug
(9) |
Sep
(39) |
Oct
(69) |
Nov
(55) |
Dec
(19) |
| 2015 |
Jan
(13) |
Feb
(21) |
Mar
(5) |
Apr
(14) |
May
(30) |
Jun
(51) |
Jul
(31) |
Aug
(12) |
Sep
(29) |
Oct
(15) |
Nov
(24) |
Dec
(16) |
| 2016 |
Jan
(62) |
Feb
(76) |
Mar
(30) |
Apr
(43) |
May
(46) |
Jun
(62) |
Jul
(21) |
Aug
(49) |
Sep
(67) |
Oct
(27) |
Nov
(26) |
Dec
(38) |
| 2017 |
Jan
(7) |
Feb
(12) |
Mar
(69) |
Apr
(59) |
May
(54) |
Jun
(40) |
Jul
(76) |
Aug
(82) |
Sep
(92) |
Oct
(51) |
Nov
(32) |
Dec
(30) |
| 2018 |
Jan
(22) |
Feb
(25) |
Mar
(34) |
Apr
(35) |
May
(37) |
Jun
(21) |
Jul
(69) |
Aug
(55) |
Sep
(17) |
Oct
(67) |
Nov
(9) |
Dec
(5) |
| 2019 |
Jan
(19) |
Feb
(12) |
Mar
(15) |
Apr
(19) |
May
|
Jun
(27) |
Jul
(27) |
Aug
(25) |
Sep
(25) |
Oct
(27) |
Nov
(10) |
Dec
(14) |
| 2020 |
Jan
(22) |
Feb
(20) |
Mar
(36) |
Apr
(40) |
May
(52) |
Jun
(35) |
Jul
(21) |
Aug
(32) |
Sep
(71) |
Oct
(27) |
Nov
(11) |
Dec
(16) |
| 2021 |
Jan
(16) |
Feb
(21) |
Mar
(21) |
Apr
(27) |
May
(17) |
Jun
|
Jul
(2) |
Aug
(22) |
Sep
(23) |
Oct
(7) |
Nov
(11) |
Dec
(28) |
| 2022 |
Jan
(23) |
Feb
(18) |
Mar
(9) |
Apr
(15) |
May
(15) |
Jun
(7) |
Jul
(8) |
Aug
(15) |
Sep
(1) |
Oct
|
Nov
(11) |
Dec
(10) |
| 2023 |
Jan
(14) |
Feb
(10) |
Mar
(11) |
Apr
(13) |
May
(2) |
Jun
(30) |
Jul
(1) |
Aug
(15) |
Sep
(13) |
Oct
(3) |
Nov
(25) |
Dec
(5) |
| 2024 |
Jan
(3) |
Feb
(10) |
Mar
(9) |
Apr
|
May
(1) |
Jun
(15) |
Jul
(7) |
Aug
(10) |
Sep
(3) |
Oct
(8) |
Nov
(6) |
Dec
(15) |
| 2025 |
Jan
(3) |
Feb
(1) |
Mar
(7) |
Apr
(5) |
May
(13) |
Jun
(16) |
Jul
(1) |
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Michael K. <mic...@ip...> - 2020-10-11 19:34:56
|
PS just letting the group know that I haven’t had any lockups since adding this workaround which is certainly a relief.
Thanks all for your help.
Regards
Michael Knill
On 21/9/20, 8:34 am, "Michael Knill" <mic...@ip...> wrote:
Thanks Lonnie for all your help.
Regards
Michael Knill
On 21/9/20, 7:37 am, "Lonnie Abelbeck" <li...@lo...> wrote:
Hi Michael,
Considering this is a very obscure kernel bug that has been around for a long time, and AstLinux 1.4.x will have it fixed ... I personally would not get carried away implementing the workaround.
BTW, the PHYETH_DISABLE_OFFLOAD workaround only applies to physical ethernet NICs.
You understand the situation, so do what you think is best.
Lonnie
> On Sep 20, 2020, at 3:45 PM, Michael Knill <mic...@ip...> wrote:
>
> Thanks Lonnie
>
> One last question; could I just blanket add this to all my systems or are there any that will certainly not be affected by this bug e.g. VM or virtual NIC?
> The plan is to have this command active by default and commented out if desired.
>
> Regards
> Michael Knill
>
> On 20/9/20, 9:58 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
>
>> Do you think I should remove PHYETH_DISABLE_OFFLOAD and try a BIOS upgrade to see if it fixes the problem?
>
> No ... first make sure setting PHYETH_DISABLE_OFFLOAD solves the issue with your DLS provider and your APU2s.
>
> After that, AstLinux 1.4.0 will be the solution without setting PHYETH_DISABLE_OFFLOAD .
>
> Ideally, you could test a 1.4-pre-release on an APU2 with the new DLS provider to make certain we have identified the issue.
> https://www.astlinux-project.org/dev.html
>
> Lonnie
>
>
>> On Sep 20, 2020, at 5:24 AM, Michael Knill <mic...@ip...> wrote:
>>
>> Yes my BIOS is quite old:
>> 3999-IPCBuild-CM1 kd # dmesg | grep DMI
>> [ 0.000000] DMI: PC Engines APU, BIOS SageBios_PCEngines_APU-45 04/05/2014
>>
>> Funny as it's a pretty new box.
>>
>> Do you think I should remove PHYETH_DISABLE_OFFLOAD and try a BIOS upgrade to see if it fixes the problem?
>> I don't think I will for existing sites as a BIOS upgrade looks pretty hard to do and I assume cannot be done remotely.
>>
>> Regards
>> Michael Knill
>>
>> On 20/9/20, 12:18 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
>>
>> Hi Michael,
>>
>> Ahhh, very good ... looks like we are on to something.
>>
>> Add it to one/some of your APU2s and let us know how it goes.
>>
>> As far as my Qotom Q190G4N, I initially had to set PHYETH_DISABLE_OFFLOAD to keep it from locking-up with sustained high network traffic but then switched the RAM SO-DIMM with another brand and did not need PHYETH_DISABLE_OFFLOAD anymore. My comments probably got you started adding PHYETH_DISABLE_OFFLOAD.
>>
>> This is a very obscure kernel bug, as such it never got back-ported to Linux 3.16.x .
>>
>> For the APU2, the BIOS could play a role in how it initializes the NICs and whether this kernel bug is triggered.
>>
>> Lonnie
>>
>>
>>
>>> On Sep 19, 2020, at 7:49 PM, Michael Knill <mic...@ip...> wrote:
>>>
>>> Awesome thanks Lonnie.
>>> Yes its all making sense now. I already have this directive in my template against the Qotom Q190G4U for some reason (should I have?)
>>> I have two Qotoms connected to the problem provider, one had this directive set already and has not failed and one did not (I forgot to change when I changed hardware) which fails.
>>> All my APU's don't have this set so all have problems with this provider.
>>>
>>> I'm thinking we have finally solved this issue.
>>> Thanks so much for your help
>>>
>>> Regards
>>> Michael Knill
>>>
>>> On 20/9/20, 9:29 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>>>
>>> I would try this first
>>> --
>>> PHYETH_DISABLE_OFFLOAD="tso gso gro"
>>> --
>>> and see if it fixes the problem.
>>>
>>> If by chance it does fix it, then it would not be needed in AstLinux 1.4.x.
>>>
>>> The PHYETH_DISABLE_OFFLOAD settings disable some of the "offload" features of the NICs in an effort to work around this (somewhat obscure) kernel bug.
>>>
>>> It all kind of makes sense that a particular provider is fragmenting packets in ways others do not, and hits this kernel bug.
>>>
>>> The PHYETH_DISABLE_OFFLOAD setting above is very "safe", only drawback is it slightly reduces network performance near the 1 Gbps level.
>>>
>>> BTW, if traffic shaping is enabled this PHYETH_DISABLE_OFFLOAD setting is already applied to external ethernet NIC(s).
>>>
>>> Lonnie
>>>
>>>
>>>
>>>> On Sep 19, 2020, at 6:09 PM, Michael Knill <mic...@ip...> wrote:
>>>>
>>>> Awesome thanks Lonnie.
>>>>
>>>> I will give it a try although I have no idea what it does!
>>>> I assume I can remove this when I go to Astlinux 1.4?
>>>>
>>>> Regards
>>>> Michael Knill
>>>>
>>>> Sent from my iPhone so please excuse my brevity.
>>>>
>>>>> On 19 Sep 2020, at 11:56 pm, Lonnie Abelbeck <li...@lo...> wrote:
>>>>>
>>>>>
>>>>> Hi Michael,
>>>>>
>>>>> Great info!
>>>>>
>>>>> Try this in your user.conf, and reboot.
>>>>> --
>>>>> PHYETH_DISABLE_OFFLOAD="tso gso gro"
>>>>> --
>>>>>
>>>>> If my hunch is correct, this kernel fix added in 4.1.17 may be related ...
>>>>>
>>>>> net: preserve IP control block during GSO segmentation
>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/include/linux/skbuff.h?h=v4.1.17&id=abefd1b4087b9b5e83e7b4e7689f8b8e3cb2899c
>>>>>
>>>>> Lonnie
>>>>>
>>>>>
>>>>>
>>>>>> On Sep 18, 2020, at 10:56 PM, Michael Knill <mic...@ip...> wrote:
>>>>>>
>>>>>> Yay some progress on this problem.
>>>>>>
>>>>>> I had my 4th site lock up yesterday. It was a site I moved from one location to another. There were no changes to the Astlinux box at all other than PPPoE credentials but after a couple of hours it locked up. So realistically the only change is the internet provider which is a new one that I am trialling and is the same provider as two of the other sites that are failing.
>>>>>>
>>>>>> As we are also using this provider in our home office, I set up another box this morning and connected the serial port not expecting anything to happen but it locked up and we captured it. Yay! It is attached.
>>>>>>
>>>>>> I'm hoping it will help the resolution of this problem.
>>>>>>
>>>>>> Regards
>>>>>> Michael Knill
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Astlinux-users mailing list
>>>>> Ast...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>>>>
>>>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>>>>> <APU Crash.log>
>>>> _______________________________________________
>>>> Astlinux-users mailing list
>>>> Ast...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>>>
>>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>>>
>>>
>>>
>>> _______________________________________________
>>> Astlinux-users mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>>
>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>>>
>>>
>>> _______________________________________________
>>> Astlinux-users mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>>
>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>>
>>
>>
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>>
>>
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>
>
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
|
|
From: nedi <ne...@gm...> - 2020-10-09 16:41:58
|
Thanks > Am 09.10.2020 um 16:47 schrieb Lonnie Abelbeck <li...@lo...>: > >> Not clear ( to me ) which current build will work. > > I'm guessing the latest AstLinux 1.4.0 may work on this, though the NIC is unknown. If not, give 1.3.10 a try. > > The limited flash storage of 1 GB will only yield a 512 MB /mnt/kd/ partition, resulting in limited voicemail storage, but may be fine for certain installs. > > For something inexpensive and new, I would also look at PC Engines apu2 (2 LAN), currently they have a sale on 2 GB RAM boards ($ 86.00 USD board-only). With 2x the RAM, 2x NICs and 4x the CPU cores of the AMD Sempron 2100+ (HP t5730). > > USD prices > https://www.pcengines.ch/newshop.php?c=4 > > Lonnie > > > > >> On Oct 9, 2020, at 8:30 AM, John Novack <jn...@co...> wrote: >> >> I have several users who have the T5730. one even has an expansion frame with a T1 card and a custom Asterisk built to work with his WE ANI >> >> It has been in use for a couple years now with no issues. Used with our CNET collectors network. >> >> Asterisk version 13.?? >> >> Not clear ( to me ) which current build will work. >> >> >> >> John Novack >> >> >> nedi wrote: >>> Hi , >>> Has anyone tried Astlinux on HP t5730 Thin Client? >>> AMD Sempron 2100+ Single Core 1.00GHz / 1GB RAM / 1GB IDE Flash Microsoft Windows XP Embedded 64bit >>> >>> Regards Nedi >>> >>> >>> >>> >>> _______________________________________________ >>> Astlinux-users mailing list >>> >>> Ast...@li... >>> https://lists.sourceforge.net/lists/listinfo/astlinux-users >>> >>> >>> Donations to support AstLinux are graciously accepted via PayPal to >>> pa...@kr... >>> . >>> >>> >> >> -- >> Dog is my Co-Pilot >> >> _______________________________________________ >> Astlinux-users mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-users >> >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: John N. <jn...@co...> - 2020-10-09 15:37:34
|
Lonnie Abelbeck wrote: >> Not clear ( to me ) which current build will work. > I'm guessing the latest AstLinux 1.4.0 may work on this, though the NIC is unknown. If not, give 1.3.10 a try. Never had any issues with any of the HP TC nics and AstLinux, up through the T5740 at least > > The limited flash storage of 1 GB will only yield a 512 MB /mnt/kd/ partition, resulting in limited voicemail storage, but may be fine for certain installs. The flash can easily be upped to 2GB for cheap, or if one obtains a 44 pin female to female ribbon cable and a 44 pin IDE flash card, then ( almost ) the sky is the limit! The T5730 is quite old, and seldom seen either new or used these days. IMO, the T5740 or newer are better choices these days in the used market for single NIC units. All the HP TC units are quite reliable though. We have many users on our collectors network that once set up, the node just works. Not a large number of users per node, nor much use of VM. YMMV John Novack -- Dog is my Co-Pilot |
|
From: Lonnie A. <li...@lo...> - 2020-10-09 14:47:49
|
> Not clear ( to me ) which current build will work. I'm guessing the latest AstLinux 1.4.0 may work on this, though the NIC is unknown. If not, give 1.3.10 a try. The limited flash storage of 1 GB will only yield a 512 MB /mnt/kd/ partition, resulting in limited voicemail storage, but may be fine for certain installs. For something inexpensive and new, I would also look at PC Engines apu2 (2 LAN), currently they have a sale on 2 GB RAM boards ($ 86.00 USD board-only). With 2x the RAM, 2x NICs and 4x the CPU cores of the AMD Sempron 2100+ (HP t5730). USD prices https://www.pcengines.ch/newshop.php?c=4 Lonnie > On Oct 9, 2020, at 8:30 AM, John Novack <jn...@co...> wrote: > > I have several users who have the T5730. one even has an expansion frame with a T1 card and a custom Asterisk built to work with his WE ANI > > It has been in use for a couple years now with no issues. Used with our CNET collectors network. > > Asterisk version 13.?? > > Not clear ( to me ) which current build will work. > > > > John Novack > > > nedi wrote: >> Hi , >> Has anyone tried Astlinux on HP t5730 Thin Client? >> AMD Sempron 2100+ Single Core 1.00GHz / 1GB RAM / 1GB IDE Flash Microsoft Windows XP Embedded 64bit >> >> Regards Nedi >> >> >> >> >> _______________________________________________ >> Astlinux-users mailing list >> >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-users >> >> >> Donations to support AstLinux are graciously accepted via PayPal to >> pa...@kr... >> . >> >> > > -- > Dog is my Co-Pilot > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: John N. <jn...@co...> - 2020-10-09 13:30:31
|
I have several users who have the T5730. one even has an expansion frame with a T1 card and a custom Asterisk built to work with his WE ANI It has been in use for a couple years now with no issues. Used with our CNET collectors network. Asterisk version 13.?? Not clear ( to me ) which current build will work. John Novack nedi wrote: > Hi , > Has anyone tried Astlinux on HP t5730 Thin Client? > AMD Sempron 2100+ Single Core 1.00GHz / 1GB RAM / 1GB IDE Flash Microsoft Windows XP Embedded 64bit > > Regards Nedi > > > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > -- Dog is my Co-Pilot |
|
From: nedi <ne...@gm...> - 2020-10-09 13:21:34
|
Hi , Has anyone tried Astlinux on HP t5730 Thin Client? AMD Sempron 2100+ Single Core 1.00GHz / 1GB RAM / 1GB IDE Flash Microsoft Windows XP Embedded 64bit Regards Nedi |
|
From: Michael K. <mic...@ip...> - 2020-10-07 06:06:36
|
Thanks guys
Not sure why this would be happening on this system as I have much busier ones that are fine but I will have a look next time it happens.
Regards
Michael Knill
On 7/10/20, 12:23 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
Thanks Darrick,
If you have a very busy (network) system, you can set in your user.conf
--
CONNTRACK=65536
--
or some higher power of 2 ... that will survive a reboot. Though higher values will use more RAM.
BTW, CONNTRACK is a firewall variable.
Lonnie
> On Oct 6, 2020, at 7:19 PM, darricklegacy <dha...@dj...> wrote:
>
> Hi Michael,
>
> I have seen this error on our system from time to time. If you are on a relatively busy network, you could exceed the 16384 value potentially. You can echo a larger value to that setting in /proc/sys/net but it will not survive a reboot.
>
> If you have a relatively small network, Lonnie is on the right track (pun intented). You can check what's in the table by parsing /proc/net and looking at ip_conntrack.
>
> Darrick
>
> On 10/6/20, 5:38 PM, "Lonnie Abelbeck" <li...@lo...> wrote:
>
> Hi Michael,
>
> I have never personally witnessed this error, but I am aware it can happen if the conntrack state table is full.
>
> By default CONNTRACK=16384 which sets the conntrack state table size.
>
> View the number states:
> System tab -> Firewall States
> --
>
> NNN Total Firewall States
> --
>
> Look to see what public TCP or UDP ports are exposed and see if someone might be probing them.
>
> Possibly you have a BitTorrent running internally ? That can create a lot of states.
>
> If you really have a super busy system there is some tuning you can do, but I would look to see if you have some publicly exposed ports that can be firewalled better.
>
> Lonnie
>
>
>
>
>
>> On Oct 6, 2020, at 4:50 PM, Michael Knill <mic...@ip...> wrote:
>>
>> Hi Group
>>
>> For the second morning in a row, my office system has been pretty much unusable with the following in the logs:
>>
>> user.warn kernel: nf_conntrack: table full, dropping packet
>>
>> Is this a DoS attack?
>> Things are fine once rebooted. Surely this wouldn't be the case with a DoS attack?
>>
>> Where should I test next?
>>
>> Thanks all.
>>
>> Regards
>
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
|
|
From: Lonnie A. <li...@lo...> - 2020-10-07 01:23:31
|
Thanks Darrick, If you have a very busy (network) system, you can set in your user.conf -- CONNTRACK=65536 -- or some higher power of 2 ... that will survive a reboot. Though higher values will use more RAM. BTW, CONNTRACK is a firewall variable. Lonnie > On Oct 6, 2020, at 7:19 PM, darricklegacy <dha...@dj...> wrote: > > Hi Michael, > > I have seen this error on our system from time to time. If you are on a relatively busy network, you could exceed the 16384 value potentially. You can echo a larger value to that setting in /proc/sys/net but it will not survive a reboot. > > If you have a relatively small network, Lonnie is on the right track (pun intented). You can check what's in the table by parsing /proc/net and looking at ip_conntrack. > > Darrick > > On 10/6/20, 5:38 PM, "Lonnie Abelbeck" <li...@lo...> wrote: > > Hi Michael, > > I have never personally witnessed this error, but I am aware it can happen if the conntrack state table is full. > > By default CONNTRACK=16384 which sets the conntrack state table size. > > View the number states: > System tab -> Firewall States > -- > > NNN Total Firewall States > -- > > Look to see what public TCP or UDP ports are exposed and see if someone might be probing them. > > Possibly you have a BitTorrent running internally ? That can create a lot of states. > > If you really have a super busy system there is some tuning you can do, but I would look to see if you have some publicly exposed ports that can be firewalled better. > > Lonnie > > > > > >> On Oct 6, 2020, at 4:50 PM, Michael Knill <mic...@ip...> wrote: >> >> Hi Group >> >> For the second morning in a row, my office system has been pretty much unusable with the following in the logs: >> >> user.warn kernel: nf_conntrack: table full, dropping packet >> >> Is this a DoS attack? >> Things are fine once rebooted. Surely this wouldn't be the case with a DoS attack? >> >> Where should I test next? >> >> Thanks all. >> >> Regards > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: darricklegacy <dha...@dj...> - 2020-10-07 00:35:38
|
Hi Michael,
I have seen this error on our system from time to time. If you are on a relatively busy network, you could exceed the 16384 value potentially. You can echo a larger value to that setting in /proc/sys/net but it will not survive a reboot.
If you have a relatively small network, Lonnie is on the right track (pun intented). You can check what's in the table by parsing /proc/net and looking at ip_conntrack.
Darrick
On 10/6/20, 5:38 PM, "Lonnie Abelbeck" <li...@lo...> wrote:
Hi Michael,
I have never personally witnessed this error, but I am aware it can happen if the conntrack state table is full.
By default CONNTRACK=16384 which sets the conntrack state table size.
View the number states:
System tab -> Firewall States
--
NNN Total Firewall States
--
Look to see what public TCP or UDP ports are exposed and see if someone might be probing them.
Possibly you have a BitTorrent running internally ? That can create a lot of states.
If you really have a super busy system there is some tuning you can do, but I would look to see if you have some publicly exposed ports that can be firewalled better.
Lonnie
> On Oct 6, 2020, at 4:50 PM, Michael Knill <mic...@ip...> wrote:
>
> Hi Group
>
> For the second morning in a row, my office system has been pretty much unusable with the following in the logs:
>
> user.warn kernel: nf_conntrack: table full, dropping packet
>
> Is this a DoS attack?
> Things are fine once rebooted. Surely this wouldn't be the case with a DoS attack?
>
> Where should I test next?
>
> Thanks all.
>
> Regards
|
|
From: Lonnie A. <li...@lo...> - 2020-10-06 22:38:09
|
Hi Michael, I have never personally witnessed this error, but I am aware it can happen if the conntrack state table is full. By default CONNTRACK=16384 which sets the conntrack state table size. View the number states: System tab -> Firewall States -- NNN Total Firewall States -- Look to see what public TCP or UDP ports are exposed and see if someone might be probing them. Possibly you have a BitTorrent running internally ? That can create a lot of states. If you really have a super busy system there is some tuning you can do, but I would look to see if you have some publicly exposed ports that can be firewalled better. Lonnie > On Oct 6, 2020, at 4:50 PM, Michael Knill <mic...@ip...> wrote: > > Hi Group > > For the second morning in a row, my office system has been pretty much unusable with the following in the logs: > > user.warn kernel: nf_conntrack: table full, dropping packet > > Is this a DoS attack? > Things are fine once rebooted. Surely this wouldn't be the case with a DoS attack? > > Where should I test next? > > Thanks all. > > Regards > Michael Knill > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: Michael K. <mic...@ip...> - 2020-10-06 21:51:20
|
Hi Group For the second morning in a row, my office system has been pretty much unusable with the following in the logs: user.warn kernel: nf_conntrack: table full, dropping packet Is this a DoS attack? Things are fine once rebooted. Surely this wouldn't be the case with a DoS attack? Where should I test next? Thanks all. Regards Michael Knill |
|
From: Lonnie A. <li...@lo...> - 2020-10-06 14:56:55
|
Announcing AstLinux Release: 1.4.0 More Info: AstLinux Project https://www.astlinux-project.org/ AstLinux 1.4.0 Highlights: * Asterisk Versions: 13.29.2, 13.36.0, 16.13.0 * Linux Kernel 4.19.146, major bump from 3.16.x series * RUNNIX, version bump to runnix-0.6.2, with Linux Kernel 4.19.146, e2fsprogs 1.45.6, util-linux 2.33.2 * WireGuard VPN, version bump, module 1.0.20200908, tools 1.0.20200827 * iproute2 (ip, tc, bridge, etc.) version bump to 4.20.0 * iptables, version bump to 1.8.4 * Fossil, version bump to 2.10.2, security fixes * acme-client, version 2.8.7, add email notify support * dnsmasq, version bump to 2.82, performance improvements and bug fixes * util-linux, version bump to 2.33.2, add 'nsenter' command * zabbix, version bump to 4.0.24 * Asterisk '13se' (stable edition) version 13.29.2 is older than latest Asterisk 13.x version but more tested, built --without-pjproject * pjsip, version bump to 2.10 * DAHDI, version bump to dahdi-linux 3.1.0 and dahdi-tools 3.1.0, required to support the new kernel Previous DAHDI_HFCS and RHINO drivers are no longer supported Add patch to return DAHDI support for (wctdm24xxp) TDM800P/AEX800 and TDM410P/AEX410 PCI cards Add patch to return DAHDI support for (wctdm) TDM400P PCI cards Add patch to return DAHDI support for (wcfxo) X100P PCI cards * Package upgrades providing important security and bug fixes Full ChangeLog: https://raw.githubusercontent.com/astlinux-project/astlinux/1.4.0/docs/ChangeLog.txt All users are encouraged to upgrade. Previous Asterisk 11.x users are encouraged to switch to the new Asterisk '13se' (stable edition). Some configuration changes will be needed, though minimal. AstLinux Team |
|
From: Lonnie A. <li...@lo...> - 2020-09-27 15:07:06
|
Release Candidate1 pre-1.4.0, please report any issues, ASAP.
The next AstLinux version will be 1.4.0, most notably switching to the Linux kernel 4.19.x LTS series.
** IMPORTANT NOTICE
-- DAHDI is now version 3.1.0 to support the new kernel, as such previous DAHDI_HFCS and RHINO drivers are no longer supported.
** The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own.
-- Linux Kernel 4.19.146 (major version bump from 3.16.x)
-- WireGuard VPN, module 1.0.20200908 (version bump), tools 1.0.20200827 (version bump)
-- iproute2 (ip, tc, bridge, etc.) version bump to 4.20.0
-- iptables, version bump to 1.8.4
-- Fossil, version bump to 2.10.2, security fixes
-- acme-client, version 2.8.7, add email notify support
-- dnsmasq, version bump to 2.82, performance improvements and bug fixes
-- util-linux, version bump to 2.33.2, add 'nsenter' command
-- zabbix, version bump to 4.0.24
-- Asterisk 13.29.2 ('13se' no change)
Older than latest Asterisk 13.x version but more tested, built --without-pjproject
-- Asterisk 13.36.0 (version bump) and 16.13.0 (version bump)
-- DAHDI, dahdi-linux 3.1.0 (version bump) and dahdi-tools 3.1.0 (version bump)
Note: Add patch to return support for (wctdm24xxp) TDM800P/AEX800 and TDM410P/AEX410 PCI cards.
Note: Add patch to return support for (wctdm) TDM400P PCI cards.
Note: Add patch to return support for (wcfxo) X100P PCI cards.
-- pjsip 2.10 (version bump)
-- Complete Pre-Release ChangeLog:
https://s3.amazonaws.com/beta.astlinux-project/astlinux-changelog/ChangeLog.txt
Updated Documentation Topics:
-- ACME (Let's Encrypt) Certificates
https://doc.astlinux-project.org/userdoc:tt_acme_certificates
The "AstLinux Pre-Release ChangeLog" and "Pre-Release Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ...
AstLinux Project -> Development
https://www.astlinux-project.org/dev.html
AstLinux Team
|
|
From: Michael K. <mic...@ip...> - 2020-09-20 22:33:47
|
Thanks Lonnie for all your help.
Regards
Michael Knill
On 21/9/20, 7:37 am, "Lonnie Abelbeck" <li...@lo...> wrote:
Hi Michael,
Considering this is a very obscure kernel bug that has been around for a long time, and AstLinux 1.4.x will have it fixed ... I personally would not get carried away implementing the workaround.
BTW, the PHYETH_DISABLE_OFFLOAD workaround only applies to physical ethernet NICs.
You understand the situation, so do what you think is best.
Lonnie
> On Sep 20, 2020, at 3:45 PM, Michael Knill <mic...@ip...> wrote:
>
> Thanks Lonnie
>
> One last question; could I just blanket add this to all my systems or are there any that will certainly not be affected by this bug e.g. VM or virtual NIC?
> The plan is to have this command active by default and commented out if desired.
>
> Regards
> Michael Knill
>
> On 20/9/20, 9:58 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
>
>> Do you think I should remove PHYETH_DISABLE_OFFLOAD and try a BIOS upgrade to see if it fixes the problem?
>
> No ... first make sure setting PHYETH_DISABLE_OFFLOAD solves the issue with your DLS provider and your APU2s.
>
> After that, AstLinux 1.4.0 will be the solution without setting PHYETH_DISABLE_OFFLOAD .
>
> Ideally, you could test a 1.4-pre-release on an APU2 with the new DLS provider to make certain we have identified the issue.
> https://www.astlinux-project.org/dev.html
>
> Lonnie
>
>
>> On Sep 20, 2020, at 5:24 AM, Michael Knill <mic...@ip...> wrote:
>>
>> Yes my BIOS is quite old:
>> 3999-IPCBuild-CM1 kd # dmesg | grep DMI
>> [ 0.000000] DMI: PC Engines APU, BIOS SageBios_PCEngines_APU-45 04/05/2014
>>
>> Funny as it's a pretty new box.
>>
>> Do you think I should remove PHYETH_DISABLE_OFFLOAD and try a BIOS upgrade to see if it fixes the problem?
>> I don't think I will for existing sites as a BIOS upgrade looks pretty hard to do and I assume cannot be done remotely.
>>
>> Regards
>> Michael Knill
>>
>> On 20/9/20, 12:18 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
>>
>> Hi Michael,
>>
>> Ahhh, very good ... looks like we are on to something.
>>
>> Add it to one/some of your APU2s and let us know how it goes.
>>
>> As far as my Qotom Q190G4N, I initially had to set PHYETH_DISABLE_OFFLOAD to keep it from locking-up with sustained high network traffic but then switched the RAM SO-DIMM with another brand and did not need PHYETH_DISABLE_OFFLOAD anymore. My comments probably got you started adding PHYETH_DISABLE_OFFLOAD.
>>
>> This is a very obscure kernel bug, as such it never got back-ported to Linux 3.16.x .
>>
>> For the APU2, the BIOS could play a role in how it initializes the NICs and whether this kernel bug is triggered.
>>
>> Lonnie
>>
>>
>>
>>> On Sep 19, 2020, at 7:49 PM, Michael Knill <mic...@ip...> wrote:
>>>
>>> Awesome thanks Lonnie.
>>> Yes its all making sense now. I already have this directive in my template against the Qotom Q190G4U for some reason (should I have?)
>>> I have two Qotoms connected to the problem provider, one had this directive set already and has not failed and one did not (I forgot to change when I changed hardware) which fails.
>>> All my APU's don't have this set so all have problems with this provider.
>>>
>>> I'm thinking we have finally solved this issue.
>>> Thanks so much for your help
>>>
>>> Regards
>>> Michael Knill
>>>
>>> On 20/9/20, 9:29 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>>>
>>> I would try this first
>>> --
>>> PHYETH_DISABLE_OFFLOAD="tso gso gro"
>>> --
>>> and see if it fixes the problem.
>>>
>>> If by chance it does fix it, then it would not be needed in AstLinux 1.4.x.
>>>
>>> The PHYETH_DISABLE_OFFLOAD settings disable some of the "offload" features of the NICs in an effort to work around this (somewhat obscure) kernel bug.
>>>
>>> It all kind of makes sense that a particular provider is fragmenting packets in ways others do not, and hits this kernel bug.
>>>
>>> The PHYETH_DISABLE_OFFLOAD setting above is very "safe", only drawback is it slightly reduces network performance near the 1 Gbps level.
>>>
>>> BTW, if traffic shaping is enabled this PHYETH_DISABLE_OFFLOAD setting is already applied to external ethernet NIC(s).
>>>
>>> Lonnie
>>>
>>>
>>>
>>>> On Sep 19, 2020, at 6:09 PM, Michael Knill <mic...@ip...> wrote:
>>>>
>>>> Awesome thanks Lonnie.
>>>>
>>>> I will give it a try although I have no idea what it does!
>>>> I assume I can remove this when I go to Astlinux 1.4?
>>>>
>>>> Regards
>>>> Michael Knill
>>>>
>>>> Sent from my iPhone so please excuse my brevity.
>>>>
>>>>> On 19 Sep 2020, at 11:56 pm, Lonnie Abelbeck <li...@lo...> wrote:
>>>>>
>>>>>
>>>>> Hi Michael,
>>>>>
>>>>> Great info!
>>>>>
>>>>> Try this in your user.conf, and reboot.
>>>>> --
>>>>> PHYETH_DISABLE_OFFLOAD="tso gso gro"
>>>>> --
>>>>>
>>>>> If my hunch is correct, this kernel fix added in 4.1.17 may be related ...
>>>>>
>>>>> net: preserve IP control block during GSO segmentation
>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/include/linux/skbuff.h?h=v4.1.17&id=abefd1b4087b9b5e83e7b4e7689f8b8e3cb2899c
>>>>>
>>>>> Lonnie
>>>>>
>>>>>
>>>>>
>>>>>> On Sep 18, 2020, at 10:56 PM, Michael Knill <mic...@ip...> wrote:
>>>>>>
>>>>>> Yay some progress on this problem.
>>>>>>
>>>>>> I had my 4th site lock up yesterday. It was a site I moved from one location to another. There were no changes to the Astlinux box at all other than PPPoE credentials but after a couple of hours it locked up. So realistically the only change is the internet provider which is a new one that I am trialling and is the same provider as two of the other sites that are failing.
>>>>>>
>>>>>> As we are also using this provider in our home office, I set up another box this morning and connected the serial port not expecting anything to happen but it locked up and we captured it. Yay! It is attached.
>>>>>>
>>>>>> I'm hoping it will help the resolution of this problem.
>>>>>>
>>>>>> Regards
>>>>>> Michael Knill
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Astlinux-users mailing list
>>>>> Ast...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>>>>
>>>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>>>>> <APU Crash.log>
>>>> _______________________________________________
>>>> Astlinux-users mailing list
>>>> Ast...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>>>
>>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>>>
>>>
>>>
>>> _______________________________________________
>>> Astlinux-users mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>>
>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>>>
>>>
>>> _______________________________________________
>>> Astlinux-users mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>>
>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>>
>>
>>
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>>
>>
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>
>
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
|
|
From: Lonnie A. <li...@lo...> - 2020-09-20 21:37:15
|
Hi Michael, Considering this is a very obscure kernel bug that has been around for a long time, and AstLinux 1.4.x will have it fixed ... I personally would not get carried away implementing the workaround. BTW, the PHYETH_DISABLE_OFFLOAD workaround only applies to physical ethernet NICs. You understand the situation, so do what you think is best. Lonnie > On Sep 20, 2020, at 3:45 PM, Michael Knill <mic...@ip...> wrote: > > Thanks Lonnie > > One last question; could I just blanket add this to all my systems or are there any that will certainly not be affected by this bug e.g. VM or virtual NIC? > The plan is to have this command active by default and commented out if desired. > > Regards > Michael Knill > > On 20/9/20, 9:58 pm, "Lonnie Abelbeck" <li...@lo...> wrote: > >> Do you think I should remove PHYETH_DISABLE_OFFLOAD and try a BIOS upgrade to see if it fixes the problem? > > No ... first make sure setting PHYETH_DISABLE_OFFLOAD solves the issue with your DLS provider and your APU2s. > > After that, AstLinux 1.4.0 will be the solution without setting PHYETH_DISABLE_OFFLOAD . > > Ideally, you could test a 1.4-pre-release on an APU2 with the new DLS provider to make certain we have identified the issue. > https://www.astlinux-project.org/dev.html > > Lonnie > > >> On Sep 20, 2020, at 5:24 AM, Michael Knill <mic...@ip...> wrote: >> >> Yes my BIOS is quite old: >> 3999-IPCBuild-CM1 kd # dmesg | grep DMI >> [ 0.000000] DMI: PC Engines APU, BIOS SageBios_PCEngines_APU-45 04/05/2014 >> >> Funny as it's a pretty new box. >> >> Do you think I should remove PHYETH_DISABLE_OFFLOAD and try a BIOS upgrade to see if it fixes the problem? >> I don't think I will for existing sites as a BIOS upgrade looks pretty hard to do and I assume cannot be done remotely. >> >> Regards >> Michael Knill >> >> On 20/9/20, 12:18 pm, "Lonnie Abelbeck" <li...@lo...> wrote: >> >> Hi Michael, >> >> Ahhh, very good ... looks like we are on to something. >> >> Add it to one/some of your APU2s and let us know how it goes. >> >> As far as my Qotom Q190G4N, I initially had to set PHYETH_DISABLE_OFFLOAD to keep it from locking-up with sustained high network traffic but then switched the RAM SO-DIMM with another brand and did not need PHYETH_DISABLE_OFFLOAD anymore. My comments probably got you started adding PHYETH_DISABLE_OFFLOAD. >> >> This is a very obscure kernel bug, as such it never got back-ported to Linux 3.16.x . >> >> For the APU2, the BIOS could play a role in how it initializes the NICs and whether this kernel bug is triggered. >> >> Lonnie >> >> >> >>> On Sep 19, 2020, at 7:49 PM, Michael Knill <mic...@ip...> wrote: >>> >>> Awesome thanks Lonnie. >>> Yes its all making sense now. I already have this directive in my template against the Qotom Q190G4U for some reason (should I have?) >>> I have two Qotoms connected to the problem provider, one had this directive set already and has not failed and one did not (I forgot to change when I changed hardware) which fails. >>> All my APU's don't have this set so all have problems with this provider. >>> >>> I'm thinking we have finally solved this issue. >>> Thanks so much for your help >>> >>> Regards >>> Michael Knill >>> >>> On 20/9/20, 9:29 am, "Lonnie Abelbeck" <li...@lo...> wrote: >>> >>> I would try this first >>> -- >>> PHYETH_DISABLE_OFFLOAD="tso gso gro" >>> -- >>> and see if it fixes the problem. >>> >>> If by chance it does fix it, then it would not be needed in AstLinux 1.4.x. >>> >>> The PHYETH_DISABLE_OFFLOAD settings disable some of the "offload" features of the NICs in an effort to work around this (somewhat obscure) kernel bug. >>> >>> It all kind of makes sense that a particular provider is fragmenting packets in ways others do not, and hits this kernel bug. >>> >>> The PHYETH_DISABLE_OFFLOAD setting above is very "safe", only drawback is it slightly reduces network performance near the 1 Gbps level. >>> >>> BTW, if traffic shaping is enabled this PHYETH_DISABLE_OFFLOAD setting is already applied to external ethernet NIC(s). >>> >>> Lonnie >>> >>> >>> >>>> On Sep 19, 2020, at 6:09 PM, Michael Knill <mic...@ip...> wrote: >>>> >>>> Awesome thanks Lonnie. >>>> >>>> I will give it a try although I have no idea what it does! >>>> I assume I can remove this when I go to Astlinux 1.4? >>>> >>>> Regards >>>> Michael Knill >>>> >>>> Sent from my iPhone so please excuse my brevity. >>>> >>>>> On 19 Sep 2020, at 11:56 pm, Lonnie Abelbeck <li...@lo...> wrote: >>>>> >>>>> >>>>> Hi Michael, >>>>> >>>>> Great info! >>>>> >>>>> Try this in your user.conf, and reboot. >>>>> -- >>>>> PHYETH_DISABLE_OFFLOAD="tso gso gro" >>>>> -- >>>>> >>>>> If my hunch is correct, this kernel fix added in 4.1.17 may be related ... >>>>> >>>>> net: preserve IP control block during GSO segmentation >>>>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/include/linux/skbuff.h?h=v4.1.17&id=abefd1b4087b9b5e83e7b4e7689f8b8e3cb2899c >>>>> >>>>> Lonnie >>>>> >>>>> >>>>> >>>>>> On Sep 18, 2020, at 10:56 PM, Michael Knill <mic...@ip...> wrote: >>>>>> >>>>>> Yay some progress on this problem. >>>>>> >>>>>> I had my 4th site lock up yesterday. It was a site I moved from one location to another. There were no changes to the Astlinux box at all other than PPPoE credentials but after a couple of hours it locked up. So realistically the only change is the internet provider which is a new one that I am trialling and is the same provider as two of the other sites that are failing. >>>>>> >>>>>> As we are also using this provider in our home office, I set up another box this morning and connected the serial port not expecting anything to happen but it locked up and we captured it. Yay! It is attached. >>>>>> >>>>>> I'm hoping it will help the resolution of this problem. >>>>>> >>>>>> Regards >>>>>> Michael Knill >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Astlinux-users mailing list >>>>> Ast...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users >>>>> >>>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >>>>> <APU Crash.log> >>>> _______________________________________________ >>>> Astlinux-users mailing list >>>> Ast...@li... >>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users >>>> >>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >>> >>> >>> >>> _______________________________________________ >>> Astlinux-users mailing list >>> Ast...@li... >>> https://lists.sourceforge.net/lists/listinfo/astlinux-users >>> >>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >>> >>> >>> _______________________________________________ >>> Astlinux-users mailing list >>> Ast...@li... >>> https://lists.sourceforge.net/lists/listinfo/astlinux-users >>> >>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >> >> >> >> _______________________________________________ >> Astlinux-users mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-users >> >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >> >> >> _______________________________________________ >> Astlinux-users mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-users >> >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: Michael K. <mic...@ip...> - 2020-09-20 20:45:49
|
Thanks Lonnie
One last question; could I just blanket add this to all my systems or are there any that will certainly not be affected by this bug e.g. VM or virtual NIC?
The plan is to have this command active by default and commented out if desired.
Regards
Michael Knill
On 20/9/20, 9:58 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
> Do you think I should remove PHYETH_DISABLE_OFFLOAD and try a BIOS upgrade to see if it fixes the problem?
No ... first make sure setting PHYETH_DISABLE_OFFLOAD solves the issue with your DLS provider and your APU2s.
After that, AstLinux 1.4.0 will be the solution without setting PHYETH_DISABLE_OFFLOAD .
Ideally, you could test a 1.4-pre-release on an APU2 with the new DLS provider to make certain we have identified the issue.
https://www.astlinux-project.org/dev.html
Lonnie
> On Sep 20, 2020, at 5:24 AM, Michael Knill <mic...@ip...> wrote:
>
> Yes my BIOS is quite old:
> 3999-IPCBuild-CM1 kd # dmesg | grep DMI
> [ 0.000000] DMI: PC Engines APU, BIOS SageBios_PCEngines_APU-45 04/05/2014
>
> Funny as it's a pretty new box.
>
> Do you think I should remove PHYETH_DISABLE_OFFLOAD and try a BIOS upgrade to see if it fixes the problem?
> I don't think I will for existing sites as a BIOS upgrade looks pretty hard to do and I assume cannot be done remotely.
>
> Regards
> Michael Knill
>
> On 20/9/20, 12:18 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
>
> Hi Michael,
>
> Ahhh, very good ... looks like we are on to something.
>
> Add it to one/some of your APU2s and let us know how it goes.
>
> As far as my Qotom Q190G4N, I initially had to set PHYETH_DISABLE_OFFLOAD to keep it from locking-up with sustained high network traffic but then switched the RAM SO-DIMM with another brand and did not need PHYETH_DISABLE_OFFLOAD anymore. My comments probably got you started adding PHYETH_DISABLE_OFFLOAD.
>
> This is a very obscure kernel bug, as such it never got back-ported to Linux 3.16.x .
>
> For the APU2, the BIOS could play a role in how it initializes the NICs and whether this kernel bug is triggered.
>
> Lonnie
>
>
>
>> On Sep 19, 2020, at 7:49 PM, Michael Knill <mic...@ip...> wrote:
>>
>> Awesome thanks Lonnie.
>> Yes its all making sense now. I already have this directive in my template against the Qotom Q190G4U for some reason (should I have?)
>> I have two Qotoms connected to the problem provider, one had this directive set already and has not failed and one did not (I forgot to change when I changed hardware) which fails.
>> All my APU's don't have this set so all have problems with this provider.
>>
>> I'm thinking we have finally solved this issue.
>> Thanks so much for your help
>>
>> Regards
>> Michael Knill
>>
>> On 20/9/20, 9:29 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>>
>> I would try this first
>> --
>> PHYETH_DISABLE_OFFLOAD="tso gso gro"
>> --
>> and see if it fixes the problem.
>>
>> If by chance it does fix it, then it would not be needed in AstLinux 1.4.x.
>>
>> The PHYETH_DISABLE_OFFLOAD settings disable some of the "offload" features of the NICs in an effort to work around this (somewhat obscure) kernel bug.
>>
>> It all kind of makes sense that a particular provider is fragmenting packets in ways others do not, and hits this kernel bug.
>>
>> The PHYETH_DISABLE_OFFLOAD setting above is very "safe", only drawback is it slightly reduces network performance near the 1 Gbps level.
>>
>> BTW, if traffic shaping is enabled this PHYETH_DISABLE_OFFLOAD setting is already applied to external ethernet NIC(s).
>>
>> Lonnie
>>
>>
>>
>>> On Sep 19, 2020, at 6:09 PM, Michael Knill <mic...@ip...> wrote:
>>>
>>> Awesome thanks Lonnie.
>>>
>>> I will give it a try although I have no idea what it does!
>>> I assume I can remove this when I go to Astlinux 1.4?
>>>
>>> Regards
>>> Michael Knill
>>>
>>> Sent from my iPhone so please excuse my brevity.
>>>
>>>> On 19 Sep 2020, at 11:56 pm, Lonnie Abelbeck <li...@lo...> wrote:
>>>>
>>>>
>>>> Hi Michael,
>>>>
>>>> Great info!
>>>>
>>>> Try this in your user.conf, and reboot.
>>>> --
>>>> PHYETH_DISABLE_OFFLOAD="tso gso gro"
>>>> --
>>>>
>>>> If my hunch is correct, this kernel fix added in 4.1.17 may be related ...
>>>>
>>>> net: preserve IP control block during GSO segmentation
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/include/linux/skbuff.h?h=v4.1.17&id=abefd1b4087b9b5e83e7b4e7689f8b8e3cb2899c
>>>>
>>>> Lonnie
>>>>
>>>>
>>>>
>>>>> On Sep 18, 2020, at 10:56 PM, Michael Knill <mic...@ip...> wrote:
>>>>>
>>>>> Yay some progress on this problem.
>>>>>
>>>>> I had my 4th site lock up yesterday. It was a site I moved from one location to another. There were no changes to the Astlinux box at all other than PPPoE credentials but after a couple of hours it locked up. So realistically the only change is the internet provider which is a new one that I am trialling and is the same provider as two of the other sites that are failing.
>>>>>
>>>>> As we are also using this provider in our home office, I set up another box this morning and connected the serial port not expecting anything to happen but it locked up and we captured it. Yay! It is attached.
>>>>>
>>>>> I'm hoping it will help the resolution of this problem.
>>>>>
>>>>> Regards
>>>>> Michael Knill
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Astlinux-users mailing list
>>>> Ast...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>>>
>>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>>>> <APU Crash.log>
>>> _______________________________________________
>>> Astlinux-users mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>>
>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>>
>>
>>
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>>
>>
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>
>
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
|
|
From: Lonnie A. <li...@lo...> - 2020-09-20 16:55:15
|
Thanks Daryl for the feedback. It is quite possible your issue was related to the GSO kernel bug, but only testing 1.3.10 with PHYETH_DISABLE_OFFLOAD="tso gso gro" would you know for sure. If you don't mind, keep running 1.4-pre-release and report any issues you may have. Lonnie > On Sep 20, 2020, at 11:35 AM, Daryl Richards via Astlinux-users <ast...@li...> wrote: > > Since updating to the 1.4 snapshot, I haven't had a crash on my APU2. Even though I didn't get a kernel dump, is it possible that it's related? > > On 2020-09-20 7:57 a.m., Lonnie Abelbeck wrote: >>> Do you think I should remove PHYETH_DISABLE_OFFLOAD and try a BIOS upgrade to see if it fixes the problem? >> No ... first make sure setting PHYETH_DISABLE_OFFLOAD solves the issue with your DLS provider and your APU2s. >> After that, AstLinux 1.4.0 will be the solution without setting PHYETH_DISABLE_OFFLOAD . >> Ideally, you could test a 1.4-pre-release on an APU2 with the new DLS provider to make certain we have identified the issue. >> https://www.astlinux-project.org/dev.html >> Lonnie >> -- > Daryl Richards > Isle Technical Services Inc. > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > |
|
From: Daryl R. <da...@is...> - 2020-09-20 16:35:20
|
Since updating to the 1.4 snapshot, I haven't had a crash on my APU2. Even though I didn't get a kernel dump, is it possible that it's related? On 2020-09-20 7:57 a.m., Lonnie Abelbeck wrote: >> Do you think I should remove PHYETH_DISABLE_OFFLOAD and try a BIOS upgrade to see if it fixes the problem? > > No ... first make sure setting PHYETH_DISABLE_OFFLOAD solves the issue with your DLS provider and your APU2s. > > After that, AstLinux 1.4.0 will be the solution without setting PHYETH_DISABLE_OFFLOAD . > > Ideally, you could test a 1.4-pre-release on an APU2 with the new DLS provider to make certain we have identified the issue. > https://www.astlinux-project.org/dev.html > > Lonnie > -- Daryl Richards Isle Technical Services Inc. |
|
From: Lonnie A. <li...@lo...> - 2020-09-20 11:57:39
|
> Do you think I should remove PHYETH_DISABLE_OFFLOAD and try a BIOS upgrade to see if it fixes the problem? No ... first make sure setting PHYETH_DISABLE_OFFLOAD solves the issue with your DLS provider and your APU2s. After that, AstLinux 1.4.0 will be the solution without setting PHYETH_DISABLE_OFFLOAD . Ideally, you could test a 1.4-pre-release on an APU2 with the new DLS provider to make certain we have identified the issue. https://www.astlinux-project.org/dev.html Lonnie > On Sep 20, 2020, at 5:24 AM, Michael Knill <mic...@ip...> wrote: > > Yes my BIOS is quite old: > 3999-IPCBuild-CM1 kd # dmesg | grep DMI > [ 0.000000] DMI: PC Engines APU, BIOS SageBios_PCEngines_APU-45 04/05/2014 > > Funny as it's a pretty new box. > > Do you think I should remove PHYETH_DISABLE_OFFLOAD and try a BIOS upgrade to see if it fixes the problem? > I don't think I will for existing sites as a BIOS upgrade looks pretty hard to do and I assume cannot be done remotely. > > Regards > Michael Knill > > On 20/9/20, 12:18 pm, "Lonnie Abelbeck" <li...@lo...> wrote: > > Hi Michael, > > Ahhh, very good ... looks like we are on to something. > > Add it to one/some of your APU2s and let us know how it goes. > > As far as my Qotom Q190G4N, I initially had to set PHYETH_DISABLE_OFFLOAD to keep it from locking-up with sustained high network traffic but then switched the RAM SO-DIMM with another brand and did not need PHYETH_DISABLE_OFFLOAD anymore. My comments probably got you started adding PHYETH_DISABLE_OFFLOAD. > > This is a very obscure kernel bug, as such it never got back-ported to Linux 3.16.x . > > For the APU2, the BIOS could play a role in how it initializes the NICs and whether this kernel bug is triggered. > > Lonnie > > > >> On Sep 19, 2020, at 7:49 PM, Michael Knill <mic...@ip...> wrote: >> >> Awesome thanks Lonnie. >> Yes its all making sense now. I already have this directive in my template against the Qotom Q190G4U for some reason (should I have?) >> I have two Qotoms connected to the problem provider, one had this directive set already and has not failed and one did not (I forgot to change when I changed hardware) which fails. >> All my APU's don't have this set so all have problems with this provider. >> >> I'm thinking we have finally solved this issue. >> Thanks so much for your help >> >> Regards >> Michael Knill >> >> On 20/9/20, 9:29 am, "Lonnie Abelbeck" <li...@lo...> wrote: >> >> I would try this first >> -- >> PHYETH_DISABLE_OFFLOAD="tso gso gro" >> -- >> and see if it fixes the problem. >> >> If by chance it does fix it, then it would not be needed in AstLinux 1.4.x. >> >> The PHYETH_DISABLE_OFFLOAD settings disable some of the "offload" features of the NICs in an effort to work around this (somewhat obscure) kernel bug. >> >> It all kind of makes sense that a particular provider is fragmenting packets in ways others do not, and hits this kernel bug. >> >> The PHYETH_DISABLE_OFFLOAD setting above is very "safe", only drawback is it slightly reduces network performance near the 1 Gbps level. >> >> BTW, if traffic shaping is enabled this PHYETH_DISABLE_OFFLOAD setting is already applied to external ethernet NIC(s). >> >> Lonnie >> >> >> >>> On Sep 19, 2020, at 6:09 PM, Michael Knill <mic...@ip...> wrote: >>> >>> Awesome thanks Lonnie. >>> >>> I will give it a try although I have no idea what it does! >>> I assume I can remove this when I go to Astlinux 1.4? >>> >>> Regards >>> Michael Knill >>> >>> Sent from my iPhone so please excuse my brevity. >>> >>>> On 19 Sep 2020, at 11:56 pm, Lonnie Abelbeck <li...@lo...> wrote: >>>> >>>> >>>> Hi Michael, >>>> >>>> Great info! >>>> >>>> Try this in your user.conf, and reboot. >>>> -- >>>> PHYETH_DISABLE_OFFLOAD="tso gso gro" >>>> -- >>>> >>>> If my hunch is correct, this kernel fix added in 4.1.17 may be related ... >>>> >>>> net: preserve IP control block during GSO segmentation >>>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/include/linux/skbuff.h?h=v4.1.17&id=abefd1b4087b9b5e83e7b4e7689f8b8e3cb2899c >>>> >>>> Lonnie >>>> >>>> >>>> >>>>> On Sep 18, 2020, at 10:56 PM, Michael Knill <mic...@ip...> wrote: >>>>> >>>>> Yay some progress on this problem. >>>>> >>>>> I had my 4th site lock up yesterday. It was a site I moved from one location to another. There were no changes to the Astlinux box at all other than PPPoE credentials but after a couple of hours it locked up. So realistically the only change is the internet provider which is a new one that I am trialling and is the same provider as two of the other sites that are failing. >>>>> >>>>> As we are also using this provider in our home office, I set up another box this morning and connected the serial port not expecting anything to happen but it locked up and we captured it. Yay! It is attached. >>>>> >>>>> I'm hoping it will help the resolution of this problem. >>>>> >>>>> Regards >>>>> Michael Knill >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Astlinux-users mailing list >>>> Ast...@li... >>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users >>>> >>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >>>> <APU Crash.log> >>> _______________________________________________ >>> Astlinux-users mailing list >>> Ast...@li... >>> https://lists.sourceforge.net/lists/listinfo/astlinux-users >>> >>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >> >> >> >> _______________________________________________ >> Astlinux-users mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-users >> >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >> >> >> _______________________________________________ >> Astlinux-users mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-users >> >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: Michael K. <mic...@ip...> - 2020-09-20 10:24:32
|
Yes my BIOS is quite old:
3999-IPCBuild-CM1 kd # dmesg | grep DMI
[ 0.000000] DMI: PC Engines APU, BIOS SageBios_PCEngines_APU-45 04/05/2014
Funny as it's a pretty new box.
Do you think I should remove PHYETH_DISABLE_OFFLOAD and try a BIOS upgrade to see if it fixes the problem?
I don't think I will for existing sites as a BIOS upgrade looks pretty hard to do and I assume cannot be done remotely.
Regards
Michael Knill
On 20/9/20, 12:18 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
Hi Michael,
Ahhh, very good ... looks like we are on to something.
Add it to one/some of your APU2s and let us know how it goes.
As far as my Qotom Q190G4N, I initially had to set PHYETH_DISABLE_OFFLOAD to keep it from locking-up with sustained high network traffic but then switched the RAM SO-DIMM with another brand and did not need PHYETH_DISABLE_OFFLOAD anymore. My comments probably got you started adding PHYETH_DISABLE_OFFLOAD.
This is a very obscure kernel bug, as such it never got back-ported to Linux 3.16.x .
For the APU2, the BIOS could play a role in how it initializes the NICs and whether this kernel bug is triggered.
Lonnie
> On Sep 19, 2020, at 7:49 PM, Michael Knill <mic...@ip...> wrote:
>
> Awesome thanks Lonnie.
> Yes its all making sense now. I already have this directive in my template against the Qotom Q190G4U for some reason (should I have?)
> I have two Qotoms connected to the problem provider, one had this directive set already and has not failed and one did not (I forgot to change when I changed hardware) which fails.
> All my APU's don't have this set so all have problems with this provider.
>
> I'm thinking we have finally solved this issue.
> Thanks so much for your help
>
> Regards
> Michael Knill
>
> On 20/9/20, 9:29 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>
> I would try this first
> --
> PHYETH_DISABLE_OFFLOAD="tso gso gro"
> --
> and see if it fixes the problem.
>
> If by chance it does fix it, then it would not be needed in AstLinux 1.4.x.
>
> The PHYETH_DISABLE_OFFLOAD settings disable some of the "offload" features of the NICs in an effort to work around this (somewhat obscure) kernel bug.
>
> It all kind of makes sense that a particular provider is fragmenting packets in ways others do not, and hits this kernel bug.
>
> The PHYETH_DISABLE_OFFLOAD setting above is very "safe", only drawback is it slightly reduces network performance near the 1 Gbps level.
>
> BTW, if traffic shaping is enabled this PHYETH_DISABLE_OFFLOAD setting is already applied to external ethernet NIC(s).
>
> Lonnie
>
>
>
>> On Sep 19, 2020, at 6:09 PM, Michael Knill <mic...@ip...> wrote:
>>
>> Awesome thanks Lonnie.
>>
>> I will give it a try although I have no idea what it does!
>> I assume I can remove this when I go to Astlinux 1.4?
>>
>> Regards
>> Michael Knill
>>
>> Sent from my iPhone so please excuse my brevity.
>>
>>> On 19 Sep 2020, at 11:56 pm, Lonnie Abelbeck <li...@lo...> wrote:
>>>
>>>
>>> Hi Michael,
>>>
>>> Great info!
>>>
>>> Try this in your user.conf, and reboot.
>>> --
>>> PHYETH_DISABLE_OFFLOAD="tso gso gro"
>>> --
>>>
>>> If my hunch is correct, this kernel fix added in 4.1.17 may be related ...
>>>
>>> net: preserve IP control block during GSO segmentation
>>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/include/linux/skbuff.h?h=v4.1.17&id=abefd1b4087b9b5e83e7b4e7689f8b8e3cb2899c
>>>
>>> Lonnie
>>>
>>>
>>>
>>>> On Sep 18, 2020, at 10:56 PM, Michael Knill <mic...@ip...> wrote:
>>>>
>>>> Yay some progress on this problem.
>>>>
>>>> I had my 4th site lock up yesterday. It was a site I moved from one location to another. There were no changes to the Astlinux box at all other than PPPoE credentials but after a couple of hours it locked up. So realistically the only change is the internet provider which is a new one that I am trialling and is the same provider as two of the other sites that are failing.
>>>>
>>>> As we are also using this provider in our home office, I set up another box this morning and connected the serial port not expecting anything to happen but it locked up and we captured it. Yay! It is attached.
>>>>
>>>> I'm hoping it will help the resolution of this problem.
>>>>
>>>> Regards
>>>> Michael Knill
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Astlinux-users mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>>
>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>>> <APU Crash.log>
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>
>
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
|
|
From: Lonnie A. <li...@lo...> - 2020-09-20 02:18:15
|
Hi Michael, Ahhh, very good ... looks like we are on to something. Add it to one/some of your APU2s and let us know how it goes. As far as my Qotom Q190G4N, I initially had to set PHYETH_DISABLE_OFFLOAD to keep it from locking-up with sustained high network traffic but then switched the RAM SO-DIMM with another brand and did not need PHYETH_DISABLE_OFFLOAD anymore. My comments probably got you started adding PHYETH_DISABLE_OFFLOAD. This is a very obscure kernel bug, as such it never got back-ported to Linux 3.16.x . For the APU2, the BIOS could play a role in how it initializes the NICs and whether this kernel bug is triggered. Lonnie > On Sep 19, 2020, at 7:49 PM, Michael Knill <mic...@ip...> wrote: > > Awesome thanks Lonnie. > Yes its all making sense now. I already have this directive in my template against the Qotom Q190G4U for some reason (should I have?) > I have two Qotoms connected to the problem provider, one had this directive set already and has not failed and one did not (I forgot to change when I changed hardware) which fails. > All my APU's don't have this set so all have problems with this provider. > > I'm thinking we have finally solved this issue. > Thanks so much for your help > > Regards > Michael Knill > > On 20/9/20, 9:29 am, "Lonnie Abelbeck" <li...@lo...> wrote: > > I would try this first > -- > PHYETH_DISABLE_OFFLOAD="tso gso gro" > -- > and see if it fixes the problem. > > If by chance it does fix it, then it would not be needed in AstLinux 1.4.x. > > The PHYETH_DISABLE_OFFLOAD settings disable some of the "offload" features of the NICs in an effort to work around this (somewhat obscure) kernel bug. > > It all kind of makes sense that a particular provider is fragmenting packets in ways others do not, and hits this kernel bug. > > The PHYETH_DISABLE_OFFLOAD setting above is very "safe", only drawback is it slightly reduces network performance near the 1 Gbps level. > > BTW, if traffic shaping is enabled this PHYETH_DISABLE_OFFLOAD setting is already applied to external ethernet NIC(s). > > Lonnie > > > >> On Sep 19, 2020, at 6:09 PM, Michael Knill <mic...@ip...> wrote: >> >> Awesome thanks Lonnie. >> >> I will give it a try although I have no idea what it does! >> I assume I can remove this when I go to Astlinux 1.4? >> >> Regards >> Michael Knill >> >> Sent from my iPhone so please excuse my brevity. >> >>> On 19 Sep 2020, at 11:56 pm, Lonnie Abelbeck <li...@lo...> wrote: >>> >>> >>> Hi Michael, >>> >>> Great info! >>> >>> Try this in your user.conf, and reboot. >>> -- >>> PHYETH_DISABLE_OFFLOAD="tso gso gro" >>> -- >>> >>> If my hunch is correct, this kernel fix added in 4.1.17 may be related ... >>> >>> net: preserve IP control block during GSO segmentation >>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/include/linux/skbuff.h?h=v4.1.17&id=abefd1b4087b9b5e83e7b4e7689f8b8e3cb2899c >>> >>> Lonnie >>> >>> >>> >>>> On Sep 18, 2020, at 10:56 PM, Michael Knill <mic...@ip...> wrote: >>>> >>>> Yay some progress on this problem. >>>> >>>> I had my 4th site lock up yesterday. It was a site I moved from one location to another. There were no changes to the Astlinux box at all other than PPPoE credentials but after a couple of hours it locked up. So realistically the only change is the internet provider which is a new one that I am trialling and is the same provider as two of the other sites that are failing. >>>> >>>> As we are also using this provider in our home office, I set up another box this morning and connected the serial port not expecting anything to happen but it locked up and we captured it. Yay! It is attached. >>>> >>>> I'm hoping it will help the resolution of this problem. >>>> >>>> Regards >>>> Michael Knill >>>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Astlinux-users mailing list >>> Ast...@li... >>> https://lists.sourceforge.net/lists/listinfo/astlinux-users >>> >>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >>> <APU Crash.log> >> _______________________________________________ >> Astlinux-users mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-users >> >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: Michael K. <mic...@ip...> - 2020-09-20 00:50:07
|
Awesome thanks Lonnie.
Yes its all making sense now. I already have this directive in my template against the Qotom Q190G4U for some reason (should I have?)
I have two Qotoms connected to the problem provider, one had this directive set already and has not failed and one did not (I forgot to change when I changed hardware) which fails.
All my APU's don't have this set so all have problems with this provider.
I'm thinking we have finally solved this issue.
Thanks so much for your help
Regards
Michael Knill
On 20/9/20, 9:29 am, "Lonnie Abelbeck" <li...@lo...> wrote:
I would try this first
--
PHYETH_DISABLE_OFFLOAD="tso gso gro"
--
and see if it fixes the problem.
If by chance it does fix it, then it would not be needed in AstLinux 1.4.x.
The PHYETH_DISABLE_OFFLOAD settings disable some of the "offload" features of the NICs in an effort to work around this (somewhat obscure) kernel bug.
It all kind of makes sense that a particular provider is fragmenting packets in ways others do not, and hits this kernel bug.
The PHYETH_DISABLE_OFFLOAD setting above is very "safe", only drawback is it slightly reduces network performance near the 1 Gbps level.
BTW, if traffic shaping is enabled this PHYETH_DISABLE_OFFLOAD setting is already applied to external ethernet NIC(s).
Lonnie
> On Sep 19, 2020, at 6:09 PM, Michael Knill <mic...@ip...> wrote:
>
> Awesome thanks Lonnie.
>
> I will give it a try although I have no idea what it does!
> I assume I can remove this when I go to Astlinux 1.4?
>
> Regards
> Michael Knill
>
> Sent from my iPhone so please excuse my brevity.
>
>> On 19 Sep 2020, at 11:56 pm, Lonnie Abelbeck <li...@lo...> wrote:
>>
>>
>> Hi Michael,
>>
>> Great info!
>>
>> Try this in your user.conf, and reboot.
>> --
>> PHYETH_DISABLE_OFFLOAD="tso gso gro"
>> --
>>
>> If my hunch is correct, this kernel fix added in 4.1.17 may be related ...
>>
>> net: preserve IP control block during GSO segmentation
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/include/linux/skbuff.h?h=v4.1.17&id=abefd1b4087b9b5e83e7b4e7689f8b8e3cb2899c
>>
>> Lonnie
>>
>>
>>
>> > On Sep 18, 2020, at 10:56 PM, Michael Knill <mic...@ip...> wrote:
>> >
>> > Yay some progress on this problem.
>> >
>> > I had my 4th site lock up yesterday. It was a site I moved from one location to another. There were no changes to the Astlinux box at all other than PPPoE credentials but after a couple of hours it locked up. So realistically the only change is the internet provider which is a new one that I am trialling and is the same provider as two of the other sites that are failing.
>> >
>> > As we are also using this provider in our home office, I set up another box this morning and connected the serial port not expecting anything to happen but it locked up and we captured it. Yay! It is attached.
>> >
>> > I'm hoping it will help the resolution of this problem.
>> >
>> > Regards
>> > Michael Knill
>> >
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>> <APU Crash.log>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
|
|
From: Lonnie A. <li...@lo...> - 2020-09-19 23:28:27
|
I would try this first -- PHYETH_DISABLE_OFFLOAD="tso gso gro" -- and see if it fixes the problem. If by chance it does fix it, then it would not be needed in AstLinux 1.4.x. The PHYETH_DISABLE_OFFLOAD settings disable some of the "offload" features of the NICs in an effort to work around this (somewhat obscure) kernel bug. It all kind of makes sense that a particular provider is fragmenting packets in ways others do not, and hits this kernel bug. The PHYETH_DISABLE_OFFLOAD setting above is very "safe", only drawback is it slightly reduces network performance near the 1 Gbps level. BTW, if traffic shaping is enabled this PHYETH_DISABLE_OFFLOAD setting is already applied to external ethernet NIC(s). Lonnie > On Sep 19, 2020, at 6:09 PM, Michael Knill <mic...@ip...> wrote: > > Awesome thanks Lonnie. > > I will give it a try although I have no idea what it does! > I assume I can remove this when I go to Astlinux 1.4? > > Regards > Michael Knill > > Sent from my iPhone so please excuse my brevity. > >> On 19 Sep 2020, at 11:56 pm, Lonnie Abelbeck <li...@lo...> wrote: >> >> >> Hi Michael, >> >> Great info! >> >> Try this in your user.conf, and reboot. >> -- >> PHYETH_DISABLE_OFFLOAD="tso gso gro" >> -- >> >> If my hunch is correct, this kernel fix added in 4.1.17 may be related ... >> >> net: preserve IP control block during GSO segmentation >> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/include/linux/skbuff.h?h=v4.1.17&id=abefd1b4087b9b5e83e7b4e7689f8b8e3cb2899c >> >> Lonnie >> >> >> >> > On Sep 18, 2020, at 10:56 PM, Michael Knill <mic...@ip...> wrote: >> > >> > Yay some progress on this problem. >> > >> > I had my 4th site lock up yesterday. It was a site I moved from one location to another. There were no changes to the Astlinux box at all other than PPPoE credentials but after a couple of hours it locked up. So realistically the only change is the internet provider which is a new one that I am trialling and is the same provider as two of the other sites that are failing. >> > >> > As we are also using this provider in our home office, I set up another box this morning and connected the serial port not expecting anything to happen but it locked up and we captured it. Yay! It is attached. >> > >> > I'm hoping it will help the resolution of this problem. >> > >> > Regards >> > Michael Knill >> > >> >> >> >> >> >> >> _______________________________________________ >> Astlinux-users mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-users >> >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >> <APU Crash.log> > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: Michael K. <mic...@ip...> - 2020-09-19 23:09:52
|
Awesome thanks Lonnie. I will give it a try although I have no idea what it does! I assume I can remove this when I go to Astlinux 1.4? Regards Michael Knill Sent from my iPhone so please excuse my brevity. On 19 Sep 2020, at 11:56 pm, Lonnie Abelbeck <li...@lo...> wrote: Hi Michael, Great info! Try this in your user.conf, and reboot. -- PHYETH_DISABLE_OFFLOAD="tso gso gro" -- If my hunch is correct, this kernel fix added in 4.1.17 may be related ... net: preserve IP control block during GSO segmentation https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/include/linux/skbuff.h?h=v4.1.17&id=abefd1b4087b9b5e83e7b4e7689f8b8e3cb2899c Lonnie > On Sep 18, 2020, at 10:56 PM, Michael Knill <mic...@ip...> wrote: > > Yay some progress on this problem. > > I had my 4th site lock up yesterday. It was a site I moved from one location to another. There were no changes to the Astlinux box at all other than PPPoE credentials but after a couple of hours it locked up. So realistically the only change is the internet provider which is a new one that I am trialling and is the same provider as two of the other sites that are failing. > > As we are also using this provider in our home office, I set up another box this morning and connected the serial port not expecting anything to happen but it locked up and we captured it. Yay! It is attached. > > I'm hoping it will help the resolution of this problem. > > Regards > Michael Knill > _______________________________________________ Astlinux-users mailing list Ast...@li... https://lists.sourceforge.net/lists/listinfo/astlinux-users Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... <APU Crash.log> |
|
From: Michael K. <mic...@ip...> - 2020-09-19 23:08:18
|
Thanks Lonnie I will set it up. Is there any way I can test it? I’m interested in whether Zabbix picks it up e.g. it tells me when a system has been rebooted. Regards Michael Knill Sent from my iPhone so please excuse my brevity. > On 20 Sep 2020, at 1:08 am, Lonnie Abelbeck <li...@lo...> wrote: > > >> On Sep 18, 2020, at 11:19 PM, Michael Knill <mic...@ip...> wrote: >> >> Is there any way I can reboot Astlinux on a kernel panic? >> Would also be good to be notified as well. >> >> Regards >> Michael Knill > > Yes, in your user.conf you can add ... > -- > KERNEL_SYSCTL="kernel.panic=3" > -- > > which will try to reboot after 3 seconds following a kernel panic. > > But, this does not always work if it locked-up tight. > > Another approach is to set WDMODULE to a hardware watchdog module or the generic "softdog" module. Some say the "sp5100_tco" should work on the APU2. > > After a little testing on my APU2 > -- > WDMODULE="sp5100_tco" > -- > works on the newer 4.19.x kernel in AstLinux 1.4-pre-release, but not for AstLinux 1.3.10 and older > > for AstLinux 1.3.10 and older, you can try > -- > WDMODULE="softdog" > -- > > > Lonnie > > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
63 messages has been excluded from this view by a project administrator.
