On 06/04/2014 08:52 PM, Keith Busch wrote:
> On Wed, 4 Jun 2014, Jens Axboe wrote:
>> On 06/04/2014 12:28 PM, Keith Busch wrote:
>> Are you testing against 3.13? You really need the current tree for this,
>> otherwise I'm sure you'll run into issues (as you appear to be :-)
>
> I'm using Matias'
On 06/04/2014 12:52 PM, Keith Busch wrote:
> On Wed, 4 Jun 2014, Jens Axboe wrote:
>> On 06/04/2014 12:28 PM, Keith Busch wrote:
>> Are you testing against 3.13? You really need the current tree for this,
>> otherwise I'm sure you'll run into issues (as you appear to be :-)
>
> I'm using Matias'
On Wed, 4 Jun 2014, Jens Axboe wrote:
On 06/04/2014 12:28 PM, Keith Busch wrote:
Are you testing against 3.13? You really need the current tree for this,
otherwise I'm sure you'll run into issues (as you appear to be :-)
I'm using Matias' current tree:
On 06/04/2014 12:28 PM, Keith Busch wrote:
> On Wed, 4 Jun 2014, Matias Bjørling wrote:
>> On 06/04/2014 12:27 AM, Keith Busch wrote:
On Tue, 3 Jun 2014, Matias Bjorling wrote:
>
> Keith, will you take the nvmemq_wip_v6 branch for a spin? Thanks!
>>>
>>> BTW, if you want to test this
On Wed, 4 Jun 2014, Matias Bjørling wrote:
On 06/04/2014 12:27 AM, Keith Busch wrote:
On Tue, 3 Jun 2014, Matias Bjorling wrote:
Keith, will you take the nvmemq_wip_v6 branch for a spin? Thanks!
BTW, if you want to test this out yourself, it's pretty simple to
recreate. I just run a simple
On 06/04/2014 12:27 AM, Keith Busch wrote:
On Tue, 3 Jun 2014, Matias Bjorling wrote:
Keith, will you take the nvmemq_wip_v6 branch for a spin? Thanks!
BTW, if you want to test this out yourself, it's pretty simple to
recreate. I just run a simple user admin program sending nvme passthrough
On 06/04/2014 12:27 AM, Keith Busch wrote:
On Tue, 3 Jun 2014, Matias Bjorling wrote:
Keith, will you take the nvmemq_wip_v6 branch for a spin? Thanks!
BTW, if you want to test this out yourself, it's pretty simple to
recreate. I just run a simple user admin program sending nvme passthrough
On Wed, 4 Jun 2014, Matias Bjørling wrote:
On 06/04/2014 12:27 AM, Keith Busch wrote:
On Tue, 3 Jun 2014, Matias Bjorling wrote:
Keith, will you take the nvmemq_wip_v6 branch for a spin? Thanks!
BTW, if you want to test this out yourself, it's pretty simple to
recreate. I just run a simple
On 06/04/2014 12:28 PM, Keith Busch wrote:
On Wed, 4 Jun 2014, Matias Bjørling wrote:
On 06/04/2014 12:27 AM, Keith Busch wrote:
On Tue, 3 Jun 2014, Matias Bjorling wrote:
Keith, will you take the nvmemq_wip_v6 branch for a spin? Thanks!
BTW, if you want to test this out yourself, it's
On Wed, 4 Jun 2014, Jens Axboe wrote:
On 06/04/2014 12:28 PM, Keith Busch wrote:
Are you testing against 3.13? You really need the current tree for this,
otherwise I'm sure you'll run into issues (as you appear to be :-)
I'm using Matias' current tree:
On 06/04/2014 12:52 PM, Keith Busch wrote:
On Wed, 4 Jun 2014, Jens Axboe wrote:
On 06/04/2014 12:28 PM, Keith Busch wrote:
Are you testing against 3.13? You really need the current tree for this,
otherwise I'm sure you'll run into issues (as you appear to be :-)
I'm using Matias' current
On 06/04/2014 08:52 PM, Keith Busch wrote:
On Wed, 4 Jun 2014, Jens Axboe wrote:
On 06/04/2014 12:28 PM, Keith Busch wrote:
Are you testing against 3.13? You really need the current tree for this,
otherwise I'm sure you'll run into issues (as you appear to be :-)
I'm using Matias' current
On Tue, 3 Jun 2014, Matias Bjorling wrote:
Keith, will you take the nvmemq_wip_v6 branch for a spin? Thanks!
BTW, if you want to test this out yourself, it's pretty simple to
recreate. I just run a simple user admin program sending nvme passthrough
commands in a tight loop, then run:
# echo
On Tue, 3 Jun 2014, Matias Bjorling wrote:
Keith, will you take the nvmemq_wip_v6 branch for a spin? Thanks!
Still fails as before:
[ 88.933881] BUG: unable to handle kernel NULL pointer dereference at
0014
[ 88.942900] IP: [] blk_mq_map_queue+0xf/0x1e
[ 88.949605] PGD
On 06/03/2014 01:06 AM, Keith Busch wrote:
> Depending on the timing, it might fail in alloc instead of free:
>
> Jun 2 16:45:40 kbgrz1 kernel: [ 265.421243] NULL pointer dereference
> at (null)
> Jun 2 16:45:40 kbgrz1 kernel: [ 265.434284] PGD 429acf067 PUD
> 42ce28067 PMD 0
> Jun
On 06/03/2014 01:06 AM, Keith Busch wrote:
Depending on the timing, it might fail in alloc instead of free:
Jun 2 16:45:40 kbgrz1 kernel: [ 265.421243] NULL pointer dereference
at (null)
Jun 2 16:45:40 kbgrz1 kernel: [ 265.434284] PGD 429acf067 PUD
42ce28067 PMD 0
Jun 2 16:45:40
On 06/03/2014 01:06 AM, Keith Busch wrote:
Depending on the timing, it might fail in alloc instead of free:
Jun 2 16:45:40 kbgrz1 kernel: [ 265.421243] NULL pointer dereference
at (null)
Jun 2 16:45:40 kbgrz1 kernel: [ 265.434284] PGD 429acf067 PUD
42ce28067 PMD 0
Jun 2 16:45:40
On 06/03/2014 01:06 AM, Keith Busch wrote:
Depending on the timing, it might fail in alloc instead of free:
Jun 2 16:45:40 kbgrz1 kernel: [ 265.421243] NULL pointer dereference
at (null)
Jun 2 16:45:40 kbgrz1 kernel: [ 265.434284] PGD 429acf067 PUD
42ce28067 PMD 0
Jun 2
On Tue, 3 Jun 2014, Matias Bjorling wrote:
Keith, will you take the nvmemq_wip_v6 branch for a spin? Thanks!
Still fails as before:
[ 88.933881] BUG: unable to handle kernel NULL pointer dereference at
0014
[ 88.942900] IP: [811c51b8] blk_mq_map_queue+0xf/0x1e
[
On Tue, 3 Jun 2014, Matias Bjorling wrote:
Keith, will you take the nvmemq_wip_v6 branch for a spin? Thanks!
BTW, if you want to test this out yourself, it's pretty simple to
recreate. I just run a simple user admin program sending nvme passthrough
commands in a tight loop, then run:
# echo
Depending on the timing, it might fail in alloc instead of free:
Jun 2 16:45:40 kbgrz1 kernel: [ 265.421243] NULL pointer dereference at
(null)
Jun 2 16:45:40 kbgrz1 kernel: [ 265.434284] PGD 429acf067 PUD 42ce28067 PMD 0
Jun 2 16:45:40 kbgrz1 kernel: [ 265.439565] Oops:
On Mon, 2 Jun 2014, Matias Bjørling wrote:
Hi Matthew and Keith,
Here is an updated patch with the feedback from the previous days. It's against
Jens' for-3.16/core tree. You may use the nvmemq_wip_review branch at:
I'm testing this on my normal hardware now. As I feared, hot removal
doesn't
On Mon, 2 Jun 2014, Matias Bjørling wrote:
Hi Matthew and Keith,
Here is an updated patch with the feedback from the previous days. It's against
Jens' for-3.16/core tree. You may use the nvmemq_wip_review branch at:
I'm testing this on my normal hardware now. As I feared, hot removal
doesn't
Depending on the timing, it might fail in alloc instead of free:
Jun 2 16:45:40 kbgrz1 kernel: [ 265.421243] NULL pointer dereference at
(null)
Jun 2 16:45:40 kbgrz1 kernel: [ 265.434284] PGD 429acf067 PUD 42ce28067 PMD 0
Jun 2 16:45:40 kbgrz1 kernel: [ 265.439565] Oops:
24 matches
Mail list logo
