Hello Florian,
On 20.06.2020 21:13, Florian Fainelli wrote:
Hi,
On 6/20/2020 10:39 AM, Gerhard Wiesinger wrote:
Can you share your network configuration again with me?
Find the network config below.
# OK: Last good known version (booting that version is also ok)
Linux bpi 5.5.18-200.fc31
Hello,
I'm having troubles with the Banana Pi-R1 router with newer kernels. No
config changes, config works well since a lot of lernel updates ...
Banana Pi-R1 is configured via systemd-networkd and uses the DSA
(Distributed Switch Architecture) with b53 switch. No visible difference
in
On 29.07.2019 10:35, Enrico Weigelt, metux IT consult wrote:
On 26.07.19 16:56, Gerhard Wiesinger wrote:
Hello,
I saw that the apu4 board is completly missing (also on 5.3rc1). Can
you please add it. Should be very easy, see below.
Still in the pipeline - don't have an apu4 board
Hello,
I saw that the apu4 board is completly missing (also on 5.3rc1). Can you
please add it. Should be very easy, see below.
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/platform/x86/pcengines-apuv2.c?h=v5.1.20
On 07.03.2019 16:31, Maxime Ripard wrote:
On Wed, Mar 06, 2019 at 09:03:00PM +0100, Gerhard Wiesinger wrote:
while true; do echo ""; echo -n
"CPU_FREQ0: "; cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq;
echo -n "CPU_F
On 06.03.2019 08:36, Maxime Ripard wrote:
Yes, there might at least 2 scenarios:
1.) Frequency switching itself is the problem
But that code is also the one being used by the BananaPro, which you
reported as stable.
Yes, BananaPro is stable (with exactly same configuration as far as I
On 05.03.2019 10:28, Maxime Ripard wrote:
On Sat, Mar 02, 2019 at 09:42:08AM +0100, Gerhard Wiesinger wrote:
On 01.03.2019 10:30, Maxime Ripard wrote:
On Thu, Feb 28, 2019 at 08:41:53PM +0100, Gerhard Wiesinger wrote:
On 28.02.2019 10:35, Maxime Ripard wrote:
On Wed, Feb 27, 2019 at 07:58
On 01.03.2019 10:30, Maxime Ripard wrote:
On Thu, Feb 28, 2019 at 08:41:53PM +0100, Gerhard Wiesinger wrote:
On 28.02.2019 10:35, Maxime Ripard wrote:
On Wed, Feb 27, 2019 at 07:58:14PM +0100, Gerhard Wiesinger wrote:
On 27.02.2019 10:20, Maxime Ripard wrote:
On Sun, Feb 24, 2019 at 09:04
On 28.02.2019 10:35, Maxime Ripard wrote:
On Wed, Feb 27, 2019 at 07:58:14PM +0100, Gerhard Wiesinger wrote:
On 27.02.2019 10:20, Maxime Ripard wrote:
On Sun, Feb 24, 2019 at 09:04:57AM +0100, Gerhard Wiesinger wrote:
Hello,
I've 3 Banana Pi R1, one running with self compiled kernel
4.7.4
On 27.02.2019 10:20, Maxime Ripard wrote:
On Sun, Feb 24, 2019 at 09:04:57AM +0100, Gerhard Wiesinger wrote:
Hello,
I've 3 Banana Pi R1, one running with self compiled kernel
4.7.4-200.BPiR1.fc24.armv7hl and old Fedora 25 which is VERY STABLE, the 2
others are running with Fedora 29 latest
Hello,
I've 3 Banana Pi R1, one running with self compiled kernel
4.7.4-200.BPiR1.fc24.armv7hl and old Fedora 25 which is VERY STABLE, the
2 others are running with Fedora 29 latest, kernel
4.20.10-200.fc29.armv7hl. I tried a lot of kernels between of around
4.11
Hello David,
The dsa b53 net driver is broken since 4.15 kernels. This patch hasn't
been merged into 4.18.latest yet (is already in net.git). Can you please
integrate it in 4.18.15.
Hello David,
The dsa b53 net driver is broken since 4.15 kernels. This patch hasn't
been merged into 4.18.latest yet (is already in net.git). Can you please
integrate it in 4.18.15.
On 27.05.2018 22:31, Florian Fainelli wrote:
Le 05/27/18 à 12:01, Gerhard Wiesinger a écrit :
On 24.05.2018 08:22, Gerhard Wiesinger wrote:
On 24.05.2018 07:29, Gerhard Wiesinger wrote:
After some analysis with Florian (thnx) we found out that the current
implementation is broken:
https
On 27.05.2018 22:31, Florian Fainelli wrote:
Le 05/27/18 à 12:01, Gerhard Wiesinger a écrit :
On 24.05.2018 08:22, Gerhard Wiesinger wrote:
On 24.05.2018 07:29, Gerhard Wiesinger wrote:
After some analysis with Florian (thnx) we found out that the current
implementation is broken:
https
On 27.05.2018 22:35, Florian Fainelli wrote:
Le 05/27/18 à 12:18, Gerhard Wiesinger a écrit :
On 27.05.2018 21:01, Gerhard Wiesinger wrote:
On 24.05.2018 08:22, Gerhard Wiesinger wrote:
On 24.05.2018 07:29, Gerhard Wiesinger wrote:
After some analysis with Florian (thnx) we found out
On 27.05.2018 22:35, Florian Fainelli wrote:
Le 05/27/18 à 12:18, Gerhard Wiesinger a écrit :
On 27.05.2018 21:01, Gerhard Wiesinger wrote:
On 24.05.2018 08:22, Gerhard Wiesinger wrote:
On 24.05.2018 07:29, Gerhard Wiesinger wrote:
After some analysis with Florian (thnx) we found out
On 27.05.2018 21:01, Gerhard Wiesinger wrote:
On 24.05.2018 08:22, Gerhard Wiesinger wrote:
On 24.05.2018 07:29, Gerhard Wiesinger wrote:
After some analysis with Florian (thnx) we found out that the
current implementation is broken:
https://patchwork.ozlabs.org/patch/836538/
https
On 27.05.2018 21:01, Gerhard Wiesinger wrote:
On 24.05.2018 08:22, Gerhard Wiesinger wrote:
On 24.05.2018 07:29, Gerhard Wiesinger wrote:
After some analysis with Florian (thnx) we found out that the
current implementation is broken:
https://patchwork.ozlabs.org/patch/836538/
https
On 24.05.2018 08:22, Gerhard Wiesinger wrote:
On 24.05.2018 07:29, Gerhard Wiesinger wrote:
After some analysis with Florian (thnx) we found out that the current
implementation is broken:
https://patchwork.ozlabs.org/patch/836538/
https://github.com/torvalds/linux/commit
On 24.05.2018 08:22, Gerhard Wiesinger wrote:
On 24.05.2018 07:29, Gerhard Wiesinger wrote:
After some analysis with Florian (thnx) we found out that the current
implementation is broken:
https://patchwork.ozlabs.org/patch/836538/
https://github.com/torvalds/linux/commit
On 24.05.2018 07:29, Gerhard Wiesinger wrote:
After some analysis with Florian (thnx) we found out that the current
implementation is broken:
https://patchwork.ozlabs.org/patch/836538/
https://github.com/torvalds/linux/commit/c499696e7901bda18385ac723b7bd27c3a4af624#diff
On 24.05.2018 07:29, Gerhard Wiesinger wrote:
After some analysis with Florian (thnx) we found out that the current
implementation is broken:
https://patchwork.ozlabs.org/patch/836538/
https://github.com/torvalds/linux/commit/c499696e7901bda18385ac723b7bd27c3a4af624#diff
After some analysis with Florian (thnx) we found out that the current
implementation is broken:
https://patchwork.ozlabs.org/patch/836538/
https://github.com/torvalds/linux/commit/c499696e7901bda18385ac723b7bd27c3a4af624#diff-a2b6f8d89e18de600e873ac3ac43fa1d
Florians comment:
After some analysis with Florian (thnx) we found out that the current
implementation is broken:
https://patchwork.ozlabs.org/patch/836538/
https://github.com/torvalds/linux/commit/c499696e7901bda18385ac723b7bd27c3a4af624#diff-a2b6f8d89e18de600e873ac3ac43fa1d
Florians comment:
On 23.05.2018 19:55, Florian Fainelli wrote:
On 05/23/2018 10:35 AM, Gerhard Wiesinger wrote:
On 23.05.2018 17:28, Florian Fainelli wrote:
And in the future (time plan)?
If you don't care about multicast then you can use those patches:
https://github.com/ffainelli/linux/commit
On 23.05.2018 19:55, Florian Fainelli wrote:
On 05/23/2018 10:35 AM, Gerhard Wiesinger wrote:
On 23.05.2018 17:28, Florian Fainelli wrote:
And in the future (time plan)?
If you don't care about multicast then you can use those patches:
https://github.com/ffainelli/linux/commit
On 23.05.2018 19:47, Florian Fainelli wrote:
On 05/23/2018 10:29 AM, Gerhard Wiesinger wrote:
On 23.05.2018 17:50, Florian Fainelli wrote:
On 05/23/2018 08:28 AM, Florian Fainelli wrote:
On 05/22/2018 09:49 PM, Gerhard Wiesinger wrote:
On 22.05.2018 22:42, Florian Fainelli wrote:
On 05/22
On 23.05.2018 19:47, Florian Fainelli wrote:
On 05/23/2018 10:29 AM, Gerhard Wiesinger wrote:
On 23.05.2018 17:50, Florian Fainelli wrote:
On 05/23/2018 08:28 AM, Florian Fainelli wrote:
On 05/22/2018 09:49 PM, Gerhard Wiesinger wrote:
On 22.05.2018 22:42, Florian Fainelli wrote:
On 05/22
On 23.05.2018 17:28, Florian Fainelli wrote:
And in the future (time plan)?
If you don't care about multicast then you can use those patches:
https://github.com/ffainelli/linux/commit/de055bf5f34e9806463ab2793e0852f5dfc380df
and you have to change the part of
On 23.05.2018 17:28, Florian Fainelli wrote:
And in the future (time plan)?
If you don't care about multicast then you can use those patches:
https://github.com/ffainelli/linux/commit/de055bf5f34e9806463ab2793e0852f5dfc380df
and you have to change the part of
On 23.05.2018 17:50, Florian Fainelli wrote:
On 05/23/2018 08:28 AM, Florian Fainelli wrote:
On 05/22/2018 09:49 PM, Gerhard Wiesinger wrote:
On 22.05.2018 22:42, Florian Fainelli wrote:
On 05/22/2018 01:16 PM, Andrew Lunn wrote:
Planned network structure will be as with 4.7.x kernels
On 23.05.2018 17:50, Florian Fainelli wrote:
On 05/23/2018 08:28 AM, Florian Fainelli wrote:
On 05/22/2018 09:49 PM, Gerhard Wiesinger wrote:
On 22.05.2018 22:42, Florian Fainelli wrote:
On 05/22/2018 01:16 PM, Andrew Lunn wrote:
Planned network structure will be as with 4.7.x kernels
On 22.05.2018 22:42, Florian Fainelli wrote:
On 05/22/2018 01:16 PM, Andrew Lunn wrote:
Planned network structure will be as with 4.7.x kernels:
br0 <=> eth0.101 <=> eth0 (vlan 101 tagged) <=> lan 1-lan4 (vlan 101
untagged pvid)
br1 <=> eth0.102 <=> eth0 (vlan 102 tagged) <=> wan (vlan 102
On 22.05.2018 22:42, Florian Fainelli wrote:
On 05/22/2018 01:16 PM, Andrew Lunn wrote:
Planned network structure will be as with 4.7.x kernels:
br0 <=> eth0.101 <=> eth0 (vlan 101 tagged) <=> lan 1-lan4 (vlan 101
untagged pvid)
br1 <=> eth0.102 <=> eth0 (vlan 102 tagged) <=> wan (vlan 102
Hello,
I'm trying to get B53 DSA switch working on the Banana Pi-R1 on Fedora
26 to run (I will upgrade to Fedora 27 and Fedora 28 when networking
works again). Previously the switch was configured with swconfig without
any problems.
Kernel: 4.16.7-100.fc26.armv7hl
b53_common: found
Hello,
I'm trying to get B53 DSA switch working on the Banana Pi-R1 on Fedora
26 to run (I will upgrade to Fedora 27 and Fedora 28 when networking
works again). Previously the switch was configured with swconfig without
any problems.
Kernel: 4.16.7-100.fc26.armv7hl
b53_common: found
On 15.09.2017 19:07, Paolo Bonzini wrote:
On 15/09/2017 16:43, Gerhard Wiesinger wrote:
On 27.08.2017 20:55, Paolo Bonzini wrote:
Il 27 ago 2017 4:48 PM, "Gerhard Wiesinger" <li...@wiesinger.com
<mailto:li...@wiesinger.com>> ha scritto:
On 27.08.2017 14 <tel:2
On 15.09.2017 19:07, Paolo Bonzini wrote:
On 15/09/2017 16:43, Gerhard Wiesinger wrote:
On 27.08.2017 20:55, Paolo Bonzini wrote:
Il 27 ago 2017 4:48 PM, "Gerhard Wiesinger" mailto:li...@wiesinger.com>> ha scritto:
On 27.08.2017 14 :03, Paolo Bonzini wrote:
On 27.08.2017 14:03, Paolo Bonzini wrote:
Il 27 ago 2017 9:49 AM, "Gerhard Wiesinger" <li...@wiesinger.com> ha
scritto:
On 17.08.2017 23:14, Gerhard Wiesinger wrote:
On 17.08.2017 22:58, Gerhard Wiesinger wrote:
On 07.08.2017 19:50, Paolo Bonzini wrote:
Not much to say, unf
On 27.08.2017 14:03, Paolo Bonzini wrote:
Il 27 ago 2017 9:49 AM, "Gerhard Wiesinger" ha
scritto:
On 17.08.2017 23:14, Gerhard Wiesinger wrote:
On 17.08.2017 22:58, Gerhard Wiesinger wrote:
On 07.08.2017 19:50, Paolo Bonzini wrote:
Not much to say, unfortunately. It's pretty muc
On 17.08.2017 23:14, Gerhard Wiesinger wrote:
On 17.08.2017 22:58, Gerhard Wiesinger wrote:
>
> On 07.08.2017 19:50, Paolo Bonzini wrote:
>
> >Not much to say, unfortunately. It's pretty much the same capabilities
> >as a Prescott/Cedar Mill processor, except that it has MS
On 17.08.2017 23:14, Gerhard Wiesinger wrote:
On 17.08.2017 22:58, Gerhard Wiesinger wrote:
>
> On 07.08.2017 19:50, Paolo Bonzini wrote:
>
> >Not much to say, unfortunately. It's pretty much the same capabilities
> >as a Prescott/Cedar Mill processor, except that it has MS
On 17.08.2017 22:58, Gerhard Wiesinger wrote:
>
> On 07.08.2017 19:50, Paolo Bonzini wrote:
>
> >Not much to say, unfortunately. It's pretty much the same capabilities
> >as a Prescott/Cedar Mill processor, except that it has MSR bitmaps. It
> >also lacks FlexPriority c
On 17.08.2017 22:58, Gerhard Wiesinger wrote:
>
> On 07.08.2017 19:50, Paolo Bonzini wrote:
>
> >Not much to say, unfortunately. It's pretty much the same capabilities
> >as a Prescott/Cedar Mill processor, except that it has MSR bitmaps. It
> >also lacks FlexPriority c
On 23.03.2017 09:38, Mike Galbraith wrote:
On Thu, 2017-03-23 at 08:16 +0100, Gerhard Wiesinger wrote:
On 21.03.2017 08:13, Mike Galbraith wrote:
On Tue, 2017-03-21 at 06:59 +0100, Gerhard Wiesinger wrote:
Is this the correct information?
Incomplete, but enough to reiterate cgroup_disable
On 23.03.2017 09:38, Mike Galbraith wrote:
On Thu, 2017-03-23 at 08:16 +0100, Gerhard Wiesinger wrote:
On 21.03.2017 08:13, Mike Galbraith wrote:
On Tue, 2017-03-21 at 06:59 +0100, Gerhard Wiesinger wrote:
Is this the correct information?
Incomplete, but enough to reiterate cgroup_disable
On 21.03.2017 08:13, Mike Galbraith wrote:
On Tue, 2017-03-21 at 06:59 +0100, Gerhard Wiesinger wrote:
Is this the correct information?
Incomplete, but enough to reiterate cgroup_disable=memory suggestion.
How to collect complete information?
Thnx.
Ciao,
Gerhard
On 21.03.2017 08:13, Mike Galbraith wrote:
On Tue, 2017-03-21 at 06:59 +0100, Gerhard Wiesinger wrote:
Is this the correct information?
Incomplete, but enough to reiterate cgroup_disable=memory suggestion.
How to collect complete information?
Thnx.
Ciao,
Gerhard
On 20.03.2017 04:05, Mike Galbraith wrote:
On Sun, 2017-03-19 at 17:02 +0100, Gerhard Wiesinger wrote:
mount | grep cgroup
Just because controllers are mounted doesn't mean they're populated. To
check that, you want to look for directories under the mount points
with a non-empty 'tasks'. You
On 20.03.2017 04:05, Mike Galbraith wrote:
On Sun, 2017-03-19 at 17:02 +0100, Gerhard Wiesinger wrote:
mount | grep cgroup
Just because controllers are mounted doesn't mean they're populated. To
check that, you want to look for directories under the mount points
with a non-empty 'tasks'. You
On 19.03.2017 16:18, Michal Hocko wrote:
On Fri 17-03-17 21:08:31, Gerhard Wiesinger wrote:
On 17.03.2017 18:13, Michal Hocko wrote:
On Fri 17-03-17 17:37:48, Gerhard Wiesinger wrote:
[...]
Why does the kernel prefer to swapin/out and not use
a.) the free memory?
It will use all the free
On 19.03.2017 16:18, Michal Hocko wrote:
On Fri 17-03-17 21:08:31, Gerhard Wiesinger wrote:
On 17.03.2017 18:13, Michal Hocko wrote:
On Fri 17-03-17 17:37:48, Gerhard Wiesinger wrote:
[...]
Why does the kernel prefer to swapin/out and not use
a.) the free memory?
It will use all the free
On 17.03.2017 21:08, Gerhard Wiesinger wrote:
On 17.03.2017 18:13, Michal Hocko wrote:
On Fri 17-03-17 17:37:48, Gerhard Wiesinger wrote:
[...]
4.11.0-0.rc2.git4.1.fc27.x86_64
There are also lockups after some runtime hours to 1 day:
Message from syslogd@myserver Mar 19 08:22:33
On 17.03.2017 21:08, Gerhard Wiesinger wrote:
On 17.03.2017 18:13, Michal Hocko wrote:
On Fri 17-03-17 17:37:48, Gerhard Wiesinger wrote:
[...]
4.11.0-0.rc2.git4.1.fc27.x86_64
There are also lockups after some runtime hours to 1 day:
Message from syslogd@myserver Mar 19 08:22:33
On 17.03.2017 18:13, Michal Hocko wrote:
On Fri 17-03-17 17:37:48, Gerhard Wiesinger wrote:
[...]
Why does the kernel prefer to swapin/out and not use
a.) the free memory?
It will use all the free memory up to min watermark which is set up
based on min_free_kbytes.
Makes sense, how is /proc
On 17.03.2017 18:13, Michal Hocko wrote:
On Fri 17-03-17 17:37:48, Gerhard Wiesinger wrote:
[...]
Why does the kernel prefer to swapin/out and not use
a.) the free memory?
It will use all the free memory up to min watermark which is set up
based on min_free_kbytes.
Makes sense, how is /proc
On 16.03.2017 10:39, Michal Hocko wrote:
On Thu 16-03-17 02:23:18, l...@pengaru.com wrote:
On Thu, Mar 16, 2017 at 10:08:44AM +0100, Michal Hocko wrote:
On Thu 16-03-17 01:47:33, l...@pengaru.com wrote:
[...]
While on the topic of understanding allocation stalls, Philip Freeman recently
On 16.03.2017 10:39, Michal Hocko wrote:
On Thu 16-03-17 02:23:18, l...@pengaru.com wrote:
On Thu, Mar 16, 2017 at 10:08:44AM +0100, Michal Hocko wrote:
On Thu 16-03-17 01:47:33, l...@pengaru.com wrote:
[...]
While on the topic of understanding allocation stalls, Philip Freeman recently
On 02.03.2017 08:17, Minchan Kim wrote:
Hi Michal,
On Tue, Feb 28, 2017 at 09:12:24AM +0100, Michal Hocko wrote:
On Tue 28-02-17 14:17:23, Minchan Kim wrote:
On Mon, Feb 27, 2017 at 10:44:49AM +0100, Michal Hocko wrote:
On Mon 27-02-17 18:02:36, Minchan Kim wrote:
[...]
>From
On 02.03.2017 08:17, Minchan Kim wrote:
Hi Michal,
On Tue, Feb 28, 2017 at 09:12:24AM +0100, Michal Hocko wrote:
On Tue 28-02-17 14:17:23, Minchan Kim wrote:
On Mon, Feb 27, 2017 at 10:44:49AM +0100, Michal Hocko wrote:
On Mon 27-02-17 18:02:36, Minchan Kim wrote:
[...]
>From
On 27.02.2017 09:27, Michal Hocko wrote:
On Sun 26-02-17 09:40:42, Gerhard Wiesinger wrote:
On 04.01.2017 10:11, Michal Hocko wrote:
The VM stops working (e.g. not pingable) after around 8h (will be restarted
automatically), happened serveral times.
Had also further OOMs which I sent
On 27.02.2017 09:27, Michal Hocko wrote:
On Sun 26-02-17 09:40:42, Gerhard Wiesinger wrote:
On 04.01.2017 10:11, Michal Hocko wrote:
The VM stops working (e.g. not pingable) after around 8h (will be restarted
automatically), happened serveral times.
Had also further OOMs which I sent
On 04.01.2017 10:11, Michal Hocko wrote:
The VM stops working (e.g. not pingable) after around 8h (will be restarted
automatically), happened serveral times.
Had also further OOMs which I sent to Mincham.
Could you post them to the mailing list as well, please?
Still OOMs on dnf update
On 04.01.2017 10:11, Michal Hocko wrote:
The VM stops working (e.g. not pingable) after around 8h (will be restarted
automatically), happened serveral times.
Had also further OOMs which I sent to Mincham.
Could you post them to the mailing list as well, please?
Still OOMs on dnf update
On 23.12.2016 03:55, Minchan Kim wrote:
On Fri, Dec 09, 2016 at 04:52:07PM +0100, Gerhard Wiesinger wrote:
On 09.12.2016 14:40, Michal Hocko wrote:
On Fri 09-12-16 08:06:25, Gerhard Wiesinger wrote:
Hello,
same with latest kernel rc, dnf still killed with OOM (but sometimes
better
On 23.12.2016 03:55, Minchan Kim wrote:
On Fri, Dec 09, 2016 at 04:52:07PM +0100, Gerhard Wiesinger wrote:
On 09.12.2016 14:40, Michal Hocko wrote:
On Fri 09-12-16 08:06:25, Gerhard Wiesinger wrote:
Hello,
same with latest kernel rc, dnf still killed with OOM (but sometimes
better
On 23.12.2016 03:55, Minchan Kim wrote:
On Fri, Dec 09, 2016 at 04:52:07PM +0100, Gerhard Wiesinger wrote:
On 09.12.2016 14:40, Michal Hocko wrote:
On Fri 09-12-16 08:06:25, Gerhard Wiesinger wrote:
Hello,
same with latest kernel rc, dnf still killed with OOM (but sometimes
better
On 23.12.2016 03:55, Minchan Kim wrote:
On Fri, Dec 09, 2016 at 04:52:07PM +0100, Gerhard Wiesinger wrote:
On 09.12.2016 14:40, Michal Hocko wrote:
On Fri 09-12-16 08:06:25, Gerhard Wiesinger wrote:
Hello,
same with latest kernel rc, dnf still killed with OOM (but sometimes
better
On 09.12.2016 22:42, Vlastimil Babka wrote:
On 12/09/2016 07:01 PM, Gerhard Wiesinger wrote:
On 09.12.2016 18:30, Michal Hocko wrote:
On Fri 09-12-16 17:58:14, Gerhard Wiesinger wrote:
On 09.12.2016 17:09, Michal Hocko wrote:
[...]
[97883.882611] Mem-Info:
[97883.883747] active_anon:2915
On 09.12.2016 22:42, Vlastimil Babka wrote:
On 12/09/2016 07:01 PM, Gerhard Wiesinger wrote:
On 09.12.2016 18:30, Michal Hocko wrote:
On Fri 09-12-16 17:58:14, Gerhard Wiesinger wrote:
On 09.12.2016 17:09, Michal Hocko wrote:
[...]
[97883.882611] Mem-Info:
[97883.883747] active_anon:2915
On 09.12.2016 18:30, Michal Hocko wrote:
On Fri 09-12-16 17:58:14, Gerhard Wiesinger wrote:
On 09.12.2016 17:09, Michal Hocko wrote:
[...]
[97883.882611] Mem-Info:
[97883.883747] active_anon:2915 inactive_anon:3376 isolated_anon:0
active_file:3902 inactive_file:3639
On 09.12.2016 18:30, Michal Hocko wrote:
On Fri 09-12-16 17:58:14, Gerhard Wiesinger wrote:
On 09.12.2016 17:09, Michal Hocko wrote:
[...]
[97883.882611] Mem-Info:
[97883.883747] active_anon:2915 inactive_anon:3376 isolated_anon:0
active_file:3902 inactive_file:3639
On 09.12.2016 17:09, Michal Hocko wrote:
On Fri 09-12-16 16:52:07, Gerhard Wiesinger wrote:
On 09.12.2016 14:40, Michal Hocko wrote:
On Fri 09-12-16 08:06:25, Gerhard Wiesinger wrote:
Hello,
same with latest kernel rc, dnf still killed with OOM (but sometimes
better).
./update.sh: line 40
On 09.12.2016 17:09, Michal Hocko wrote:
On Fri 09-12-16 16:52:07, Gerhard Wiesinger wrote:
On 09.12.2016 14:40, Michal Hocko wrote:
On Fri 09-12-16 08:06:25, Gerhard Wiesinger wrote:
Hello,
same with latest kernel rc, dnf still killed with OOM (but sometimes
better).
./update.sh: line 40
On 09.12.2016 14:40, Michal Hocko wrote:
On Fri 09-12-16 08:06:25, Gerhard Wiesinger wrote:
Hello,
same with latest kernel rc, dnf still killed with OOM (but sometimes
better).
./update.sh: line 40: 1591 Killed ${EXE} update ${PARAMS}
(does dnf clean all;dnf update)
Linux
On 09.12.2016 14:40, Michal Hocko wrote:
On Fri 09-12-16 08:06:25, Gerhard Wiesinger wrote:
Hello,
same with latest kernel rc, dnf still killed with OOM (but sometimes
better).
./update.sh: line 40: 1591 Killed ${EXE} update ${PARAMS}
(does dnf clean all;dnf update)
Linux
On 09.12.2016 16:52, Gerhard Wiesinger wrote:
On 09.12.2016 14:40, Michal Hocko wrote:
On Fri 09-12-16 08:06:25, Gerhard Wiesinger wrote:
Hello,
same with latest kernel rc, dnf still killed with OOM (but sometimes
better).
./update.sh: line 40: 1591 Killed ${EXE} update
On 09.12.2016 16:52, Gerhard Wiesinger wrote:
On 09.12.2016 14:40, Michal Hocko wrote:
On Fri 09-12-16 08:06:25, Gerhard Wiesinger wrote:
Hello,
same with latest kernel rc, dnf still killed with OOM (but sometimes
better).
./update.sh: line 40: 1591 Killed ${EXE} update
On 09.12.2016 14:40, Michal Hocko wrote:
On Fri 09-12-16 08:06:25, Gerhard Wiesinger wrote:
Hello,
same with latest kernel rc, dnf still killed with OOM (but sometimes
better).
./update.sh: line 40: 1591 Killed ${EXE} update ${PARAMS}
(does dnf clean all;dnf update)
Linux
On 09.12.2016 14:40, Michal Hocko wrote:
On Fri 09-12-16 08:06:25, Gerhard Wiesinger wrote:
Hello,
same with latest kernel rc, dnf still killed with OOM (but sometimes
better).
./update.sh: line 40: 1591 Killed ${EXE} update ${PARAMS}
(does dnf clean all;dnf update)
Linux
x86_64 x86_64 GNU/Linux
Updated bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1314697
Any chance to get it fixed in 4.9.0 release?
Ciao,
Gerhard
On 30.11.2016 08:20, Gerhard Wiesinger wrote:
Hello,
See also:
Bug 1314697 - Kernel 4.4.3-300.fc23.x86_64 is not stable inside a KVM VM
https
x86_64 x86_64 GNU/Linux
Updated bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1314697
Any chance to get it fixed in 4.9.0 release?
Ciao,
Gerhard
On 30.11.2016 08:20, Gerhard Wiesinger wrote:
Hello,
See also:
Bug 1314697 - Kernel 4.4.3-300.fc23.x86_64 is not stable inside a KVM VM
https
Hello,
There is another major kernel OOPS which is still not fixed over a year
Bug 1279188 - bind-chroot causes kernel to crash on restart (mount with
bind option):
https://bugzilla.redhat.com/show_bug.cgi?id=1279188
Can you please fix it.
Thnx.
Ciao,
Gerhard
Hello,
There is another major kernel OOPS which is still not fixed over a year
Bug 1279188 - bind-chroot causes kernel to crash on restart (mount with
bind option):
https://bugzilla.redhat.com/show_bug.cgi?id=1279188
Can you please fix it.
Thnx.
Ciao,
Gerhard
Hello,
I'm having out of memory situations with my "low memory" VMs in KVM
under Fedora (Kernel 4.7, 4.8 and also before). They started to get more
and more sensitive to OOM. I recently found the following info:
Hello,
I'm having out of memory situations with my "low memory" VMs in KVM
under Fedora (Kernel 4.7, 4.8 and also before). They started to get more
and more sensitive to OOM. I recently found the following info:
Hello,
See also:
Bug 1314697 - Kernel 4.4.3-300.fc23.x86_64 is not stable inside a KVM VM
https://bugzilla.redhat.com/show_bug.cgi?id=1314697
Ciao,
Gerhard
On 30.11.2016 08:10, Gerhard Wiesinger wrote:
Hello,
I'm having out of memory situations with my "low memory" VMs in KVM
un
Hello,
See also:
Bug 1314697 - Kernel 4.4.3-300.fc23.x86_64 is not stable inside a KVM VM
https://bugzilla.redhat.com/show_bug.cgi?id=1314697
Ciao,
Gerhard
On 30.11.2016 08:10, Gerhard Wiesinger wrote:
Hello,
I'm having out of memory situations with my "low memory" VMs in KVM
un
On 08.11.2015 18:20, Greg KH wrote:
On Sun, Nov 08, 2015 at 02:51:01PM +0100, Gerhard Wiesinger wrote:
On 25.10.2015 17:29, Greg KH wrote:
On Sun, Oct 25, 2015 at 11:48:54AM +0100, Gerhard Wiesinger wrote:
On 25.10.2015 10:46, Willy Tarreau wrote:
ipset *triggered* the problem. The whole
On 08.11.2015 18:20, Greg KH wrote:
On Sun, Nov 08, 2015 at 02:51:01PM +0100, Gerhard Wiesinger wrote:
On 25.10.2015 17:29, Greg KH wrote:
On Sun, Oct 25, 2015 at 11:48:54AM +0100, Gerhard Wiesinger wrote:
On 25.10.2015 10:46, Willy Tarreau wrote:
ipset *triggered* the problem. The whole
On 25.10.2015 17:29, Greg KH wrote:
On Sun, Oct 25, 2015 at 11:48:54AM +0100, Gerhard Wiesinger wrote:
On 25.10.2015 10:46, Willy Tarreau wrote:
ipset *triggered* the problem. The whole stack dump would tell more.
OK, find the stack traces in the bug report:
https://bugzilla.redhat.com
On 25.10.2015 17:29, Greg KH wrote:
On Sun, Oct 25, 2015 at 11:48:54AM +0100, Gerhard Wiesinger wrote:
On 25.10.2015 10:46, Willy Tarreau wrote:
ipset *triggered* the problem. The whole stack dump would tell more.
OK, find the stack traces in the bug report:
https://bugzilla.redhat.com
On 26.10.2015 09:58, Jozsef Kadlecsik wrote:
On Sun, 25 Oct 2015, Gerhard Wiesinger wrote:
Also any idea regarding the second isssue? Or do you think it has the
same root cause?
Looking at your RedHat bugzilla report, the "nf_conntrack: table full,
dropping packet" and "
On 25.10.2015 22:53, Jozsef Kadlecsik wrote:
On Sun, 25 Oct 2015, Gerhard Wiesinger wrote:
Any further ideas?
Does it crash without counters? That could narrow down where to look for.
Hello Jozsef,
it doesn't crash i I don't use the counters so far. So there must be a
bug
On 25.10.2015 22:53, Jozsef Kadlecsik wrote:
On Sun, 25 Oct 2015, Gerhard Wiesinger wrote:
Any further ideas?
Does it crash without counters? That could narrow down where to look for.
Hello Jozsef,
it doesn't crash i I don't use the counters so far. So there must be a
bug
On 26.10.2015 09:58, Jozsef Kadlecsik wrote:
On Sun, 25 Oct 2015, Gerhard Wiesinger wrote:
Also any idea regarding the second isssue? Or do you think it has the
same root cause?
Looking at your RedHat bugzilla report, the "nf_conntrack: table full,
dropping packet" and "
On 25.10.2015 21:08, Gerhard Wiesinger wrote:
On 25.10.2015 20:46, Jozsef Kadlecsik wrote:
Hi,
On Sun, 25 Oct 2015, Gerhard Wiesinger wrote:
On 25.10.2015 10:46, Willy Tarreau wrote:
ipset *triggered* the problem. The whole stack dump would tell more.
OK, find the stack traces in the bug
On 25.10.2015 20:46, Jozsef Kadlecsik wrote:
Hi,
On Sun, 25 Oct 2015, Gerhard Wiesinger wrote:
On 25.10.2015 10:46, Willy Tarreau wrote:
ipset *triggered* the problem. The whole stack dump would tell more.
OK, find the stack traces in the bug report:
https://bugzilla.redhat.com/show_bug.cgi
On 25.10.2015 17:29, Greg KH wrote:
On Sun, Oct 25, 2015 at 11:48:54AM +0100, Gerhard Wiesinger wrote:
On 25.10.2015 10:46, Willy Tarreau wrote:
ipset *triggered* the problem. The whole stack dump would tell more.
OK, find the stack traces in the bug report:
https://bugzilla.redhat.com
1 - 100 of 121 matches
Mail list logo
