Re: regression since 2.1.3 (solaris/zfs)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mar 5, 2014, at 9:27 AM, Robin P. Blanchard <robin@xxxxxxxxxx> wrote:

> 
> On Mar 5, 2014, at 11:18 AM, Jens Axboe <axboe@xxxxxxxxx> wrote:
> 
>> On 2014-03-05 09:11, Robin P. Blanchard wrote:
>>> 
>>> On Mar 3, 2014, at 10:25 AM, Jens Axboe <axboe@xxxxxxxxx> wrote:
>>> 
>>>> On 03/02/2014 07:59 AM, Robin P. Blanchard wrote:
>>>>> My config file has direct=0, which until 2.1.4 worked as expected.
>>>>> Things seem to regress since.
>>>>> 
>>>>> I apologize in advance if this has already been reported. Please
>>>>> let me know what I can do to further help (truss/debug).
>>>> 
>>>> This isn't a known issue, so thanks for reporting it. The easiest way to debug this is to git bisect it. Looks like you are running from the tar balls, but I assume you have git installed? I'm assuming fio-2.1.3 worked for you - if not, just replace fio-2.1.3 in the below with whatever latest version did work. If you do, the cheat sheet is something ala:
>>>> 
>>>> $ git clone git://git.kernel.dk/fio
>>>> $ cd fio; make
>>>> $ git bisect start
>>>> $ git bisect good fio-2.1.3
>>>> $ git bisect bad fio-2.1.4
>>>> 
>>>> This starts the bisect series, now do:
>>>> 
>>>> $ make clean; make
>>>> 
>>>> and re-run your direct=0 job file. If it worked, then you do
>>>> 
>>>> $ git bisect good
>>>> 
>>>> and if not, you do git bisect bad instead. This gets you a new point in the tree to test, so repeat the make clean; make and re-run the test.
>>>> Keep doing this good/bad iteration until fio tells you what commit broke the test for you. Then send those results here!
>>>> 
>>>> --
>>>> Jens Axboe
>>>> 
>>> 
>>> 
>>> Here’s where it started working again:
>>> 
>>> # git bisect good
>>> Bisecting: 4 revisions left to test after this (roughly 2 steps)
>>> [3bb0a7b0fda9945973f799ab253c70d3cb0e5c8b] howto: Fix redundant entries
>>> 
>>> Let me know how else I can help.
>> 
>> Please keep going until it tells you what the definitively bad commit is. It'll end up spitting out that info, if you keep doing git bisect good/bad on each test point. You need just ~2 more tests after this one.
>> 
>> -- 
>> Jens Axboe
>> 
> 
> Here you go:
> 
> # git bisect good
> ddc0cc31a2b75b1c7dde870c8867af11fa44db92 is the first bad commit
> commit ddc0cc31a2b75b1c7dde870c8867af11fa44db92
> Author: Jens Axboe <axboe@xxxxxxxxx>
> Date:   Fri Oct 11 10:27:28 2013 -0600
> 
>    ppc: disable CPU clock until we can detect whether we have it or not
> 
>    The child segfault test should catch it, however it does not on
>    AIX at least.
> 
>    Signed-off-by: Jens Axboe <axboe@xxxxxxxxx>

Hmm, that can’t possibly be correct. Would you mind redoing the bisection,
just to double check?

Thanks!

— 
Jens Axboe



--
To unsubscribe from this list: send the line "unsubscribe fio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel]     [Linux SCSI]     [Linux IDE]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux