Hi Coly,
is this the deadlock I reported some weeks ago?
Greets,
Stefan
Excuse my typo sent from my mobile phone.
Am 27.09.2018 um 17:53 schrieb Eddie Chapman mailto:ed...@ehuk.net>>:
> On 27/09/18 16:23, Coly Li wrote:
>> On 9/27/18 9:45 PM, guoju wrote:
>>> After write SSD completed, bcache
Hi Coly,
is this the deadlock I reported some weeks ago?
Greets,
Stefan
Excuse my typo sent from my mobile phone.
Am 27.09.2018 um 17:53 schrieb Eddie Chapman mailto:ed...@ehuk.net>>:
> On 27/09/18 16:23, Coly Li wrote:
>> On 9/27/18 9:45 PM, guoju wrote:
>>> After write SSD completed, bcache
Am 10.09.2018 um 22:08 schrieb David Rientjes:
> On Fri, 7 Sep 2018, Michal Hocko wrote:
>
>> From: Michal Hocko
>>
>> Andrea has noticed [1] that a THP allocation might be really disruptive
>> when allocated on NUMA system with the local node full or hard to
>> reclaim. Stefan has posted an
Am 10.09.2018 um 22:08 schrieb David Rientjes:
> On Fri, 7 Sep 2018, Michal Hocko wrote:
>
>> From: Michal Hocko
>>
>> Andrea has noticed [1] that a THP allocation might be really disruptive
>> when allocated on NUMA system with the local node full or hard to
>> reclaim. Stefan has posted an
Hello,
whlie using this path i got another stall - which i never saw under
kernel 4.4. Here is the trace:
[305111.932698] INFO: task ksmtuned:1399 blocked for more than 120 seconds.
[305111.933612] Tainted: G 4.12.0+105-ph #1
[305111.934456] "echo 0 >
Hello,
whlie using this path i got another stall - which i never saw under
kernel 4.4. Here is the trace:
[305111.932698] INFO: task ksmtuned:1399 blocked for more than 120 seconds.
[305111.933612] Tainted: G 4.12.0+105-ph #1
[305111.934456] "echo 0 >
Am 08.09.2016 um 19:33 schrieb Shaohua Li:
> On Thu, Sep 08, 2016 at 10:16:59AM -0600, Jens Axboe wrote:
>> On 09/08/2016 02:23 AM, Stefan Priebe - Profihost AG wrote:
>>> Hi,
>>>
>>> while trying Kernel 4.8-rc5 my raid5 breaks every few minutes.
>&
Am 08.09.2016 um 19:33 schrieb Shaohua Li:
> On Thu, Sep 08, 2016 at 10:16:59AM -0600, Jens Axboe wrote:
>> On 09/08/2016 02:23 AM, Stefan Priebe - Profihost AG wrote:
>>> Hi,
>>>
>>> while trying Kernel 4.8-rc5 my raid5 breaks every few minutes.
>&
Hi,
while trying Kernel 4.8-rc5 my raid5 breaks every few minutes.
Trace:
[ cut here ]
kernel BUG at block/blk-core.c:2032!
invalid opcode: [#1] SMP
Modules linked in: netconsole ipt_REJECT nf_reject_ipv4 xt_multiport
iptable_filter ip_tables x_tables 8021q garp
Hi,
while trying Kernel 4.8-rc5 my raid5 breaks every few minutes.
Trace:
[ cut here ]
kernel BUG at block/blk-core.c:2032!
invalid opcode: [#1] SMP
Modules linked in: netconsole ipt_REJECT nf_reject_ipv4 xt_multiport
iptable_filter ip_tables x_tables 8021q garp
Am 31.05.2016 um 09:31 schrieb Dave Chinner:
> On Tue, May 31, 2016 at 08:11:42AM +0200, Stefan Priebe - Profihost AG wrote:
>>> I'm half tempted at this point to mostly ignore this mm/ behavour
>>> because we are moving down the path of removing buffer heads from
>>
Am 31.05.2016 um 09:31 schrieb Dave Chinner:
> On Tue, May 31, 2016 at 08:11:42AM +0200, Stefan Priebe - Profihost AG wrote:
>>> I'm half tempted at this point to mostly ignore this mm/ behavour
>>> because we are moving down the path of removing buffer heads from
>>
Am 31.05.2016 um 09:31 schrieb Dave Chinner:
> On Tue, May 31, 2016 at 08:11:42AM +0200, Stefan Priebe - Profihost AG wrote:
>>> I'm half tempted at this point to mostly ignore this mm/ behavour
>>> because we are moving down the path of removing buffer heads from
>>
Am 31.05.2016 um 09:31 schrieb Dave Chinner:
> On Tue, May 31, 2016 at 08:11:42AM +0200, Stefan Priebe - Profihost AG wrote:
>>> I'm half tempted at this point to mostly ignore this mm/ behavour
>>> because we are moving down the path of removing buffer heads from
>>
Hi Dave,
Am 31.05.2016 um 08:07 schrieb Dave Chinner:
> On Tue, May 31, 2016 at 12:59:04PM +0900, Minchan Kim wrote:
>> On Tue, May 31, 2016 at 12:55:09PM +1000, Dave Chinner wrote:
>>> On Tue, May 31, 2016 at 10:07:24AM +0900, Minchan Kim wrote:
On Tue, May 31, 2016 at 08:36:57AM +1000,
Hi Dave,
Am 31.05.2016 um 08:07 schrieb Dave Chinner:
> On Tue, May 31, 2016 at 12:59:04PM +0900, Minchan Kim wrote:
>> On Tue, May 31, 2016 at 12:55:09PM +1000, Dave Chinner wrote:
>>> On Tue, May 31, 2016 at 10:07:24AM +0900, Minchan Kim wrote:
On Tue, May 31, 2016 at 08:36:57AM +1000,
Am 21.03.2016 um 14:38 schrieb Greg KH:
> On Mon, Mar 21, 2016 at 11:52:23AM +0100, Stefan Priebe - Profihost AG wrote:
>>
>> Am 20.03.2016 um 22:41 schrieb Greg KH:
>>> On Sun, Mar 20, 2016 at 10:27:23PM +0100, Stefan Priebe wrote:
>>>>
>>>>
Am 21.03.2016 um 14:38 schrieb Greg KH:
> On Mon, Mar 21, 2016 at 11:52:23AM +0100, Stefan Priebe - Profihost AG wrote:
>>
>> Am 20.03.2016 um 22:41 schrieb Greg KH:
>>> On Sun, Mar 20, 2016 at 10:27:23PM +0100, Stefan Priebe wrote:
>>>>
>>>>
Am 20.03.2016 um 22:41 schrieb Greg KH:
> On Sun, Mar 20, 2016 at 10:27:23PM +0100, Stefan Priebe wrote:
>>
>> Am 19.03.2016 um 23:26 schrieb Vlastimil Babka:
>>> On 03/17/2016 07:45 PM, Greg KH wrote:
On Thu, Mar 17, 2016 at 07:38:03PM +0100, Stefan Priebe wrote:
> Hi,
>
> while
Am 20.03.2016 um 22:41 schrieb Greg KH:
> On Sun, Mar 20, 2016 at 10:27:23PM +0100, Stefan Priebe wrote:
>>
>> Am 19.03.2016 um 23:26 schrieb Vlastimil Babka:
>>> On 03/17/2016 07:45 PM, Greg KH wrote:
On Thu, Mar 17, 2016 at 07:38:03PM +0100, Stefan Priebe wrote:
> Hi,
>
> while
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 "netlink: Fix
>> autobind race
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 "netlink: Fix
>> autobind race
> 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.
>>
> Am 02.12.2015 um 12:40 schrieb Hannes Frederic Sowa
> <han...@stressinduktion.org>:
>
> Hello Stefan,
>
> Stefan Priebe - Profihost AG <s.pri...@profihost.ag> writes:
>
>
>> here are the results.
>>
>> It works with 4.1.
>> It
: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
015 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 PM, Stefan Priebe - Prof
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 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 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 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 threa
fff8800b16cf000 15 4410001 000 20
1542
8800b1168800 15 4294962900 000 20
7978
8800b7088800 15 0 0000 0 0 0 2 0
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
>>> would be nice to get some certainty.
>>
>>
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
>>
>> cat /proc/net/netlink
>
>
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
>>> would be nice to get some certainty.
>>
>>
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
>>
>> cat /proc/net/netlink
>
>
fff8800b16cf000 15 4410001 000 20
1542
8800b1168800 15 4294962900 000 20
7978
8800b7088800 15 0 0000 0 0 0 2 0
5
8800b71c9800 16 0 000 20
15
f
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 threa
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,
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},
Am 21.07.2015 um 23:15 schrieb Thomas Gleixner:
> On Tue, 21 Jul 2015, Stefan Priebe wrote:
>> Am 20.07.2015 um 12:53 schrieb Thomas Gleixner:
>>> On Mon, 20 Jul 2015, Stefan Priebe - Profihost AG wrote:
>>>> Hello list,
>>>>
>>>> i've 36
Am 21.07.2015 um 23:15 schrieb Thomas Gleixner:
On Tue, 21 Jul 2015, Stefan Priebe wrote:
Am 20.07.2015 um 12:53 schrieb Thomas Gleixner:
On Mon, 20 Jul 2015, Stefan Priebe - Profihost AG wrote:
Hello list,
i've 36 servers all running vanilla 3.18.18 kernel which have a very
high disk
Am 20.07.2015 um 12:53 schrieb Thomas Gleixner:
> On Mon, 20 Jul 2015, Stefan Priebe - Profihost AG wrote:
>> Hello list,
>>
>> i've 36 servers all running vanilla 3.18.18 kernel which have a very
>> high disk and network load.
>>
>> Since a few days
Hello list,
i've 36 servers all running vanilla 3.18.18 kernel which have a very
high disk and network load.
Since a few days i encounter regular the following error messages and
pretty often completely hanging disk i/o:
[535040.439859] do_IRQ: 0.126 No irq handler for vector (irq -1)
Hello list,
i've 36 servers all running vanilla 3.18.18 kernel which have a very
high disk and network load.
Since a few days i encounter regular the following error messages and
pretty often completely hanging disk i/o:
[535040.439859] do_IRQ: 0.126 No irq handler for vector (irq -1)
Am 20.07.2015 um 12:53 schrieb Thomas Gleixner:
On Mon, 20 Jul 2015, Stefan Priebe - Profihost AG wrote:
Hello list,
i've 36 servers all running vanilla 3.18.18 kernel which have a very
high disk and network load.
Since a few days i encounter regular the following error messages and
pretty
Am 16.06.2014 23:30, schrieb Francois Romieu:
> Stefan Priebe - Profihost AG :
> [...]
>> That sounds great! Is there anything I can do or some code I can port to
>> veth?
>
> You may add an empty handler for .ndo_poll_controller in drivers/net/veth.c
> and give
Am 16.06.2014 23:30, schrieb Francois Romieu:
Stefan Priebe - Profihost AG s.pri...@profihost.ag :
[...]
That sounds great! Is there anything I can do or some code I can port to
veth?
You may add an empty handler for .ndo_poll_controller in drivers/net/veth.c
and give it a try on current
> Am 16.06.2014 um 21:12 schrieb Cong Wang :
>
> On Mon, Jun 16, 2014 at 12:05 PM, Stefan Priebe - Profihost AG
> wrote:
>>
>>> Am 16.06.2014 um 20:51 schrieb Cong Wang :
>>>
>>> On Mon, Jun 16, 2014 at 11:41 AM, Stefan Priebe - Profihost AG
&
> Am 16.06.2014 um 20:51 schrieb Cong Wang :
>
> On Mon, Jun 16, 2014 at 11:41 AM, Stefan Priebe - Profihost AG
> wrote:
>>
>>> Am 16.06.2014 um 20:05 schrieb Cong Wang :
>>>
>>> On Mon, Jun 16, 2014 at 5:51 AM, Stefan Priebe - Profihost AG
>&g
> Am 16.06.2014 um 20:05 schrieb Cong Wang :
>
> On Mon, Jun 16, 2014 at 5:51 AM, Stefan Priebe - Profihost AG
> wrote:
>> Hi,
>>
>> i'm using a vanilla 3.10.43 kernel and netconsole on top of a bridge.
>>
>> netconsole is used with vmbr0 (bridge)
Hi,
i'm using a vanilla 3.10.43 kernel and netconsole on top of a bridge.
netconsole is used with vmbr0 (bridge) which is on top of bond0.
If i want to add another bridge to vmbr0 is fails as long as netconsole
is in use.
# brctl addif vmbr0 fwpr2004p0
can't add fwpr2004p0 to bridge vmbr0:
Hi,
i'm using a vanilla 3.10.43 kernel and netconsole on top of a bridge.
netconsole is used with vmbr0 (bridge) which is on top of bond0.
If i want to add another bridge to vmbr0 is fails as long as netconsole
is in use.
# brctl addif vmbr0 fwpr2004p0
can't add fwpr2004p0 to bridge vmbr0:
Am 16.06.2014 um 20:05 schrieb Cong Wang cw...@twopensource.com:
On Mon, Jun 16, 2014 at 5:51 AM, Stefan Priebe - Profihost AG
s.pri...@profihost.ag wrote:
Hi,
i'm using a vanilla 3.10.43 kernel and netconsole on top of a bridge.
netconsole is used with vmbr0 (bridge) which is on top
Am 16.06.2014 um 20:51 schrieb Cong Wang cw...@twopensource.com:
On Mon, Jun 16, 2014 at 11:41 AM, Stefan Priebe - Profihost AG
s.pri...@profihost.ag wrote:
Am 16.06.2014 um 20:05 schrieb Cong Wang cw...@twopensource.com:
On Mon, Jun 16, 2014 at 5:51 AM, Stefan Priebe - Profihost AG
Am 16.06.2014 um 21:12 schrieb Cong Wang cw...@twopensource.com:
On Mon, Jun 16, 2014 at 12:05 PM, Stefan Priebe - Profihost AG
s.pri...@profihost.ag wrote:
Am 16.06.2014 um 20:51 schrieb Cong Wang cw...@twopensource.com:
On Mon, Jun 16, 2014 at 11:41 AM, Stefan Priebe - Profihost AG
Hi ChinmayVS,
Am 20.11.2013 14:34, schrieb Chinmay V S:
> Hi Stefan,
>
> Christoph is bang on right. To further elaborate upon this, here is
> what is happening in the above case :
> By using DIRECT, SYNC/DSYNC flags on a block device (i.e. bypassing
> the file-systems layer), essentially you
Hello,
while struggling about an application beeing so slow on my SSD and
having high I/O Waits while the app is using the raw block device i've
detected that this is caused by open the block device with O_DSYNC.
I've used dd and fio with oflags=direct,dsync / --direct=1 and --sync=1
and got
Hello,
while struggling about an application beeing so slow on my SSD and
having high I/O Waits while the app is using the raw block device i've
detected that this is caused by open the block device with O_DSYNC.
I've used dd and fio with oflags=direct,dsync / --direct=1 and --sync=1
and got
Hi ChinmayVS,
Am 20.11.2013 14:34, schrieb Chinmay V S:
Hi Stefan,
Christoph is bang on right. To further elaborate upon this, here is
what is happening in the above case :
By using DIRECT, SYNC/DSYNC flags on a block device (i.e. bypassing
the file-systems layer), essentially you are
Thanks! No crashes since your fix.
Stefan
This mail was sent with my iPhone.
Am 30.08.2013 um 23:15 schrieb Kent Overstreet :
> GFP_NOIO means we could be getting called recursively - mca_alloc() ->
> mca_data_alloc() - definitely can't use mutex_lock(bucket_lock) then.
> Whoops.
>
>
Thanks! No crashes since your fix.
Stefan
This mail was sent with my iPhone.
Am 30.08.2013 um 23:15 schrieb Kent Overstreet k...@daterainc.com:
GFP_NOIO means we could be getting called recursively - mca_alloc() -
mca_data_alloc() - definitely can't use mutex_lock(bucket_lock) then.
Whoops.
] SyS_pread64+0x97/0xa0
>>>> 2013-08-26 21:05:29 [] system_call_fastpath+0x16/0x1b
>>>> 2013-08-26 21:05:29 INFO: task ceph-osd:8896 blocked for more than 120
>>>> seconds.
>>>> 2013-08-26 21:05:29 "echo 0 > /proc/sys/kernel/hung_task_time
, schrieb Stefan Priebe - Profihost AG:
great!
Everything seems to work fine now! Except read_dirty always going to
negative values after a reboot.
Stefan
Am 22.08.2013 08:02, schrieb Kent Overstreet:
On Thu, Aug 22, 2013 at 07:59:04AM +0200, Stefan Priebe wrote
great!
Everything seems to work fine now! Except read_dirty always going to
negative values after a reboot.
Stefan
Am 22.08.2013 08:02, schrieb Kent Overstreet:
> On Thu, Aug 22, 2013 at 07:59:04AM +0200, Stefan Priebe wrote:
>>
>>> schedule_timeout() is not the same as
>>>
great!
Everything seems to work fine now! Except read_dirty always going to
negative values after a reboot.
Stefan
Am 22.08.2013 08:02, schrieb Kent Overstreet:
On Thu, Aug 22, 2013 at 07:59:04AM +0200, Stefan Priebe wrote:
schedule_timeout() is not the same as
Am 20.08.2013 10:01, schrieb Stefan Priebe - Profihost AG:
> Am 20.08.2013 00:27, schrieb Kent Overstreet:
>> On Mon, Aug 19, 2013 at 12:09:24AM +0200, Stefan Priebe wrote:
>>>
>>> Vanilla 3.10.7 + bcache: Fix a writeback performance regression
>>>
>&g
Am 20.08.2013 00:27, schrieb Kent Overstreet:
> On Mon, Aug 19, 2013 at 12:09:24AM +0200, Stefan Priebe wrote:
>>
>> Vanilla 3.10.7 + bcache: Fix a writeback performance regression
>>
>> http://pastebin.com/raw.php?i=LXZk4cMH
>
> Whoops, at first I thought this was the same bug as one I'd already
Am 20.08.2013 00:27, schrieb Kent Overstreet:
On Mon, Aug 19, 2013 at 12:09:24AM +0200, Stefan Priebe wrote:
Vanilla 3.10.7 + bcache: Fix a writeback performance regression
http://pastebin.com/raw.php?i=LXZk4cMH
Whoops, at first I thought this was the same bug as one I'd already been
Am 20.08.2013 10:01, schrieb Stefan Priebe - Profihost AG:
Am 20.08.2013 00:27, schrieb Kent Overstreet:
On Mon, Aug 19, 2013 at 12:09:24AM +0200, Stefan Priebe wrote:
Vanilla 3.10.7 + bcache: Fix a writeback performance regression
http://pastebin.com/raw.php?i=LXZk4cMH
Whoops, at first I
Hi,
bcache: Fix a writeback performance regression
this one results in 3.10 into hung tasks in bcache_writeback read_dirty.
Stefan
Am 15.08.2013 08:43, schrieb Stefan Priebe - Profihost AG:
> Am 15.08.2013 00:59, schrieb Kent Overstreet:
>> Jens, here's the latest bcache fixes. So
Hi,
bcache: Fix a writeback performance regression
this one results in 3.10 into hung tasks in bcache_writeback read_dirty.
Stefan
Am 15.08.2013 08:43, schrieb Stefan Priebe - Profihost AG:
Am 15.08.2013 00:59, schrieb Kent Overstreet:
Jens, here's the latest bcache fixes. Some urgent stuff
Am 15.08.2013 00:59, schrieb Kent Overstreet:
> Jens, here's the latest bcache fixes. Some urgent stuff in here:
>
>
> The following changes since commit 79826c35eb99cd3c0873b8396f45fa26c87fb0b0:
>
> bcache: Allocation kthread fixes (2013-07-12 00:22:49 -0700)
>
> are available in the git
Am 15.08.2013 00:59, schrieb Kent Overstreet:
Jens, here's the latest bcache fixes. Some urgent stuff in here:
The following changes since commit 79826c35eb99cd3c0873b8396f45fa26c87fb0b0:
bcache: Allocation kthread fixes (2013-07-12 00:22:49 -0700)
are available in the git repository
Hello list,
today i kvm host crashed running vanilla kernel 3.8.9.
The call trace looks like this:
Kernel panic - not syncing: Watchdog detected hard LOCKUP on cpu 18
Pid: 29053, comm: kvm Tainted: G O 3.8.9+16-ph #1
Call Trace:
[] panic+0xbf/0x1df
[] ? native_sched_clock+0x13/0x80
[]
Hello list,
today i kvm host crashed running vanilla kernel 3.8.9.
The call trace looks like this:
Kernel panic - not syncing: Watchdog detected hard LOCKUP on cpu 18
Pid: 29053, comm: kvm Tainted: G O 3.8.9+16-ph #1
Call Trace:
NMI [8150a86b] panic+0xbf/0x1df
[8100ae73] ?
e
bridge on top of the VLANs.
Greets,
Stefan
Am 07.02.2013 12:22, schrieb Patrick McHardy:
> On Thu, Feb 07, 2013 at 11:56:38AM +0100, Stefan Priebe - Profihost AG wrote:
>> Hello list,
>>
>> this was tested using vanilla 3.7.6 kernel.
>>
>> When i add a vlan to an ethernet de
.
Greets,
Stefan
Am 07.02.2013 12:22, schrieb Patrick McHardy:
On Thu, Feb 07, 2013 at 11:56:38AM +0100, Stefan Priebe - Profihost AG wrote:
Hello list,
this was tested using vanilla 3.7.6 kernel.
When i add a vlan to an ethernet device supporting gvrp everything is
fine until this ethernet
can confirm - this fixed it!
Am 06.08.2012 14:37, schrieb Avi Kivity:
On 08/06/2012 03:12 PM, Avi Kivity wrote:
On 08/06/2012 11:46 AM, Stefan Priebe - Profihost AG wrote:
But still i got the segfault and core dump - this is my main problem? I
mean qemu-kvm master isn't declared as stable. So
>Am 06.08.2012 10:36, schrieb Avi Kivity:
On 08/05/2012 10:00 PM, Stefan Priebe wrote:
So here are 3 backtraces from booting the rescue system:
http://pastebin.com/raw.php?i=xCy2pEcP
To me they all look the same.
They are. What version of qemu are you using?
latest stable-1.1 branch
Am 06.08.2012 10:36, schrieb Avi Kivity:
On 08/05/2012 10:00 PM, Stefan Priebe wrote:
So here are 3 backtraces from booting the rescue system:
http://pastebin.com/raw.php?i=xCy2pEcP
To me they all look the same.
They are. What version of qemu are you using?
latest stable-1.1 branch
can confirm - this fixed it!
Am 06.08.2012 14:37, schrieb Avi Kivity:
On 08/06/2012 03:12 PM, Avi Kivity wrote:
On 08/06/2012 11:46 AM, Stefan Priebe - Profihost AG wrote:
But still i got the segfault and core dump - this is my main problem? I
mean qemu-kvm master isn't declared as stable. So
Am 01.08.2012 11:53, schrieb Avi Kivity:
On 08/01/2012 12:42 PM, Stefan Priebe - Profihost AG wrote:
Am 01.08.2012 11:33, schrieb Avi Kivity:
So here are 3 backtraces from booting the rescue system:
http://pastebin.com/raw.php?i=xCy2pEcP
To me they all look the same.
They are. What version
Am 01.08.2012 11:33, schrieb Avi Kivity:
So here are 3 backtraces from booting the rescue system:
http://pastebin.com/raw.php?i=xCy2pEcP
To me they all look the same.
They are. What version of qemu are you using?
latest stable-1.1 branch (1.1.1) - which works fine with latest RHEL6
Hi,
ok i found a faster way to trigger this. Just boot the ubuntu rescue system.
So here are 3 backtraces from booting the rescue system:
http://pastebin.com/raw.php?i=xCy2pEcP
To me they all look the same.
Thanks!
Stefan
Am 01.08.2012 10:44, schrieb Avi Kivity:
On 07/31/2012 08:37 PM,
Hi,
ok i found a faster way to trigger this. Just boot the ubuntu rescue system.
So here are 3 backtraces from booting the rescue system:
http://pastebin.com/raw.php?i=xCy2pEcP
To me they all look the same.
Thanks!
Stefan
Am 01.08.2012 10:44, schrieb Avi Kivity:
On 07/31/2012 08:37 PM,
Am 01.08.2012 11:33, schrieb Avi Kivity:
So here are 3 backtraces from booting the rescue system:
http://pastebin.com/raw.php?i=xCy2pEcP
To me they all look the same.
They are. What version of qemu are you using?
latest stable-1.1 branch (1.1.1) - which works fine with latest RHEL6
Am 01.08.2012 11:53, schrieb Avi Kivity:
On 08/01/2012 12:42 PM, Stefan Priebe - Profihost AG wrote:
Am 01.08.2012 11:33, schrieb Avi Kivity:
So here are 3 backtraces from booting the rescue system:
http://pastebin.com/raw.php?i=xCy2pEcP
To me they all look the same.
They are. What version
Hello list,
i hope it is correct to list the maintainers of kvm. While trying to
install ubuntu 12.04 amd64 on a kvm based vm the KVM process segfaults
while ubuntu tries to detect the HW:
kvm[2978]: segfault at 7fb90d9035e0 ip 7fb90d9035e0
sp7fff652e4ed8 error 15
This does not
Hello list,
i hope it is correct to list the maintainers of kvm. While trying to
install ubuntu 12.04 amd64 on a kvm based vm the KVM process segfaults
while ubuntu tries to detect the HW:
kvm[2978]: segfault at 7fb90d9035e0 ip 7fb90d9035e0
sp7fff652e4ed8 error 15
This does not
92 matches
Mail list logo
