uck (Vorsitzender)
Am 30.04.20 um 12:55 schrieb Ido Schimmel:
> On Wed, Apr 29, 2020 at 10:52:35PM +0200, Stefan Priebe - Profihost AG wrote:
>> Hello,
>>
>> while running a stable vanilla kernel 4.19.115 i'm reproducably get this
>> one:
>>
>> watch
Hello Nikolay,
Am 29.04.20 um 23:23 schrieb Nikolay Aleksandrov:
> On 4/29/20 11:52 PM, Stefan Priebe - Profihost AG wrote:
>> Hello,
>>
>> while running a stable vanilla kernel 4.19.115 i'm reproducably get this
>> one:
>>
>> watchdog: BUG: soft lo
Hello,
while running a stable vanilla kernel 4.19.115 i'm reproducably get this
one:
watchdog: BUG: soft lockup - CPU#38 stuck for 22s! [bridge:3570653]
...
Call
Trace:nbp_vlan_delete+0x59/0xa0br_vlan_info+0x66/0xd0br_afspec+0x18c/0x1d0br_dellink+0x74/0xd0rtnl_bridge_dellink+0x110/0x220rtnetlin
Hi Herbert,
Am 07.12.2015 um 02:20 schrieb Herbert Xu:
> On Sun, Dec 06, 2015 at 09:56:34PM +0100, Stefan Priebe wrote:
>> Hi Herbert,
>>
>> i think i found the issue in 4.1 with netlink. Somebody made a
>> mistake while backporting or cherry-picking your patch &qu
12PM +0100, Stefan Priebe wrote:
* 9f87e0c - (2 months ago) netlink: Replace rhash_portid with bound
- Herbert Xu
* 35e9890 - (3 months ago) netlink: Fix autobind race condition that
leads to zero port ID - Herbert Xu
* 30c6472 - (7 months ago) netlink: Use random autobind rover - Herbert Xu
These thr
Hello Philipp,
Am 05.12.2015 um 15:19 schrieb Philipp Matthias Hahn:
Hello Hannes,
On Wed, Dec 02, 2015 at 12:40:32PM +0100, Hannes Frederic Sowa wrote:
git bisect tells me it stopped working after those two commits were applied:
commit d48623677191e0f035d7afd344f92cf880b01f8e
Author: Herbert
) netlink: rename private flags and states -
Nicolas Dichtel
* 0356126 - (2 days ago) Revert "netlink: don't hold mutex in rcu
callback when releasing mmapd ring" - Stefan Priebe
* 231d0da - (2 days ago) Revert "netlink: make sure -EBUSY won't escape
from netlink_insert
> Am 02.12.2015 um 12:40 schrieb Hannes Frederic Sowa
> :
>
> Hello Stefan,
>
> Stefan Priebe - Profihost AG writes:
>
>
>> here are the results.
>>
>> It works with 4.1.
>> It works with 4.2.
>> It does not work with 4.1.13.
>>
:44, Stefan Priebe - Profihost AG wrote:
>> Am 19.11.2015 um 20:51 schrieb Stefan Priebe:
>>>
>>> Am 19.11.2015 um 14:19 schrieb Florian Weimer:
>>>> On 11/19/2015 01:46 PM, Stefan Priebe - Profihost AG wrote:
>>>>
>>>>> I can try Kerne
Am 23.11.2015 um 13:57 schrieb Hannes Frederic Sowa:
> On Mon, Nov 23, 2015, at 13:44, Stefan Priebe - Profihost AG wrote:
>> Am 19.11.2015 um 20:51 schrieb Stefan Priebe:
>>>
>>> Am 19.11.2015 um 14:19 schrieb Florian Weimer:
>>>> On 11/19/2015 01:46
Am 19.11.2015 um 20:51 schrieb Stefan Priebe:
>
> Am 19.11.2015 um 14:19 schrieb Florian Weimer:
>> On 11/19/2015 01:46 PM, Stefan Priebe - Profihost AG wrote:
>>
>>> I can try Kernel 4.4-rc1 next week. Or something else?
>>
>> I found this bug r
Am 19.11.2015 um 14:19 schrieb Florian Weimer:
On 11/19/2015 01:46 PM, Stefan Priebe - Profihost AG wrote:
I can try Kernel 4.4-rc1 next week. Or something else?
I found this bug report which indicates that 4.1.10 works:
<https://issues.asterisk.org/jira/browse/ASTERISK-25251>
Am 19.11.2015 um 13:41 schrieb Hannes Frederic Sowa:
> On Thu, Nov 19, 2015, at 12:43, Stefan Priebe - Profihost AG wrote:
>>
>> Am 19.11.2015 um 12:41 schrieb Hannes Frederic Sowa:
>>> On Thu, Nov 19, 2015, at 10:56, Stefan Priebe - Profihost AG wrote:
>>>>
Am 19.11.2015 um 12:41 schrieb Hannes Frederic Sowa:
> On Thu, Nov 19, 2015, at 10:56, Stefan Priebe - Profihost AG wrote:
>> OK it had a livelock again. It just took more time.
>>
>> So here is the data:
>
> Thanks, I couldn't reproduce it so far with simple
fff8800b16cf000 15 4410001 000 20
1542
8800b1168800 15 4294962900 000 20
7978
8800b7088800 15 0 0000 0 00 20
5
8800b71c9800 16 0 000 20
15
f
Am 19.11.2015 um 10:44 schrieb Florian Weimer:
> On 11/18/2015 10:36 PM, Stefan Priebe wrote:
>
>>> please try to get a backtrace with debugging information. It is likely
>>> that this is the make_request/__check_pf functionality in glibc, but it
>>> wo
Am 18.11.2015 um 22:22 schrieb Hannes Frederic Sowa:
> On Wed, Nov 18, 2015, at 22:20, Stefan Priebe wrote:
>> you mean just:
>> la /proc/$pid/fd
>
> ls -l /proc/pid/fd/
>
> the numbers in brackets in return from readlink are the inode numbers.
>
>> and
>
Am 18.11.2015 um 22:40 schrieb Hannes Frederic Sowa:
On Wed, Nov 18, 2015, at 22:36, Stefan Priebe wrote:
sorry here it is. What I'm wondering is why is there ipv6 stuff? I don't
have ipv6 except for link local. Could it be this one?
https://bugzilla.redhat.com/show_bug.cgi?id=
Am 18.11.2015 um 22:18 schrieb Florian Weimer:
On 11/18/2015 09:23 PM, Stefan Priebe wrote:
Am 17.11.2015 um 20:43 schrieb Thomas Gleixner:
On Tue, 17 Nov 2015, Stefan Priebe wrote:
I've now also two gdb backtraces from two crashes:
http://pastebin.com/raw.php?i=yih5jNt8
http://pastebi
Am 18.11.2015 um 22:18 schrieb Florian Weimer:
On 11/18/2015 09:23 PM, Stefan Priebe wrote:
Am 17.11.2015 um 20:43 schrieb Thomas Gleixner:
On Tue, 17 Nov 2015, Stefan Priebe wrote:
I've now also two gdb backtraces from two crashes:
http://pastebin.com/raw.php?i=yih5jNt8
Am 18.11.2015 um 22:00 schrieb Hannes Frederic Sowa:
On Wed, Nov 18, 2015, at 21:23, Stefan Priebe wrote:
Am 17.11.2015 um 20:43 schrieb Thomas Gleixner:
On Tue, 17 Nov 2015, Stefan Priebe wrote:
I've now also two gdb backtraces from two crashes:
http://pastebin.com/raw.php?i=yih
Am 17.11.2015 um 20:43 schrieb Thomas Gleixner:
On Tue, 17 Nov 2015, Stefan Priebe wrote:
I've now also two gdb backtraces from two crashes:
http://pastebin.com/raw.php?i=yih5jNt8
http://pastebin.com/raw.php?i=kGEcvH4T
They don't tell me anything as I have no idea of the inner w
Am 17.11.2015 um 20:15 schrieb Thomas Gleixner:
On Tue, 17 Nov 2015, Stefan Priebe - Profihost AG wrote:
since Upgrading our Asterisk System from Kernel 3.18.17 to 4.1.13 it
deadlocks every few hours (kill -9 is the only thing working). Booting
with 3.18 again let it run smooth again.
An
Hello,
since Upgrading our Asterisk System from Kernel 3.18.17 to 4.1.13 it
deadlocks every few hours (kill -9 is the only thing working). Booting
with 3.18 again let it run smooth again.
An strace shows asterisk is looping like this:
[pid 6068] timerfd_gettime(8, , {it_interval={0, 2000},
Hello,
i hope somebody has an idea for my problem and may point me to the right
direction. Alle servers run kernel 3.18.14.
My problem is that i can't archieve more than 20Mbit/s using a single
TCP stream and i've no further ideas how to solve it.
reduced Network Map
Server A
|
Linux GW Serve
25 matches
Mail list logo
