Re: WARNING at libata-core.c:5015 in 2.6.39-rc3-wl+, then lockup. (bisected)

Re: WARNING at libata-core.c:5015 in 2.6.39-rc3-wl+, then lockup. (bisected)

[Jeff Garzik]

On 04/15/2011 01:03 PM, Ben Greear wrote:
> Ok, it took a while, but I think I have this thing somewhat bisected.
>
> Starting at commit 4cc4d24efce4672f9b0e7fa27963770ae602998f, I see
> hard-drive
> issues. Commits right before this (in git bisect) crash in the
> networking code
> quite often, but the hard-drive logic seems to work at least.
>
> In later builds (ie, -rc3), the crashes and warnings are different, but
> they have something to do with the file system. It's difficult to bisect
> it any better because of all the instability...
>
>
> Here are some console logs from a
> 4cc4d24efce4672f9b0e7fa27963770ae602998f boot:

(linux-ide added to CC)

hmmm...  that's a merge commit.  Any chance you could mark an individual 
commit bad, to narrow things down a bit more?  Run "git help bisect" and 
check out helpful sections "Avoiding testing a commit" and "Bisect skip".

	Jeff

Re: WARNING at libata-core.c:5015 in 2.6.39-rc3-wl+, then lockup. (bisected)

[Ben Greear]

On 04/15/2011 10:57 AM, Jeff Garzik wrote:
> On 04/15/2011 01:03 PM, Ben Greear wrote:
>> Ok, it took a while, but I think I have this thing somewhat bisected.
>>
>> Starting at commit 4cc4d24efce4672f9b0e7fa27963770ae602998f, I see
>> hard-drive
>> issues. Commits right before this (in git bisect) crash in the
>> networking code
>> quite often, but the hard-drive logic seems to work at least.
>>
>> In later builds (ie, -rc3), the crashes and warnings are different, but
>> they have something to do with the file system. It's difficult to bisect
>> it any better because of all the instability...
>>
>>
>> Here are some console logs from a
>> 4cc4d24efce4672f9b0e7fa27963770ae602998f boot:
>
> (linux-ide added to CC)
>
> hmmm... that's a merge commit. Any chance you could mark an individual
> commit bad, to narrow things down a bit more? Run "git help bisect" and
> check out helpful sections "Avoiding testing a commit" and "Bisect skip".

What do I want to skip or avoid testing though?  Does bisect not know how
to deal with merges?

Here is the log, in case that helps:

4cc4d24efce4672f9b0e7fa27963770ae602998f is the first bad commit
[greearb@build-32 linux-2.6]$ git bisect log
git bisect start
# bad: [85f2e689a5c8fb6ed8fdbee00109e7f6e5fefcb6] Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mjg59/platform-drivers-x86
git bisect bad 85f2e689a5c8fb6ed8fdbee00109e7f6e5fefcb6
# good: [521cb40b0c44418a4fd36dc633f575813d59a43d] Linux 2.6.38
git bisect good 521cb40b0c44418a4fd36dc633f575813d59a43d
# skip: [ec0afc9311adcfb10b90e547c23250f63939f990] Merge branch 'kvm-updates/2.6.39' of git://git.kernel.org/pub/scm/virt/kvm/kvm
git bisect skip ec0afc9311adcfb10b90e547c23250f63939f990
# good: [a99eff39c0549fe68fed150d39ec0c750e5ce1f1] powerpc: Document the Open PIC device tree binding
git bisect good a99eff39c0549fe68fed150d39ec0c750e5ce1f1
# bad: [17e75d82518ac3146966b64adc109344fcc80f8a] ARM: mach-shmobile: convert boards to use linux/mmc/sh_mobile_sdhi.h
git bisect bad 17e75d82518ac3146966b64adc109344fcc80f8a
# bad: [4cc4d24efce4672f9b0e7fa27963770ae602998f] Merge git://git.kernel.org/pub/scm/linux/kernel/git/lethal/fbdev-2.6
git bisect bad 4cc4d24efce4672f9b0e7fa27963770ae602998f
# good: [943fc810bdc9c0fce5cc66bdb65b42d699241aa6] MAINTAINERS: update SFI pattern
git bisect good 943fc810bdc9c0fce5cc66bdb65b42d699241aa6
# good: [3486740a4f32a6a466f5ac931654d154790ba648] userns: security: make capabilities relative to the user namespace
git bisect good 3486740a4f32a6a466f5ac931654d154790ba648
# good: [38d2620ea40c2f9a5f17d6488bf004973570279c] svga: Make svga_set_timings() take an iomem regbase pointer.
git bisect good 38d2620ea40c2f9a5f17d6488bf004973570279c
# good: [2f284c846331fa44be1300a3c2c3e85800268a00] Merge branch 'devel' of master.kernel.org:/home/rmk/linux-2.6-arm
git bisect good 2f284c846331fa44be1300a3c2c3e85800268a00
# good: [d6244bc0ed0c52a795e6f4dcab3886daf3e74fac] fbcon: Bugfix soft cursor detection in Tile Blitting
git bisect good d6244bc0ed0c52a795e6f4dcab3886daf3e74fac
# good: [26947f8c8f9598209001cdcd31bb2162a2e54691] proc: disable mem_write after exec
git bisect good 26947f8c8f9598209001cdcd31bb2162a2e54691
# good: [d958c62c0cf43bb9c7dcd9833a35335ae72856f7] MAINTAINERS: Add file pattern for fb dt bindings.
git bisect good d958c62c0cf43bb9c7dcd9833a35335ae72856f7
# good: [198214a7ee50375fa71a65e518341980cfd4b2f0] proc: enable writing to /proc/pid/mem
git bisect good 198214a7ee50375fa71a65e518341980cfd4b2f0
# good: [b81a618dcd3ea99de292dbe624f41ca68f464376] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6
git bisect good b81a618dcd3ea99de292dbe624f41ca68f464376
# good: [56be1416453c31d32f984328b5193489ab63ffcf] MAINTAINERS: de-orphan fbdev.
git bisect good 56be1416453c31d32f


Thanks,
Ben

>
> Jeff
>


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: WARNING at libata-core.c:5015 in 2.6.39-rc3-wl+, then lockup. (bisected)

[Ben Greear]

On 04/15/2011 11:05 AM, Ben Greear wrote:
> On 04/15/2011 10:57 AM, Jeff Garzik wrote:
>> On 04/15/2011 01:03 PM, Ben Greear wrote:
>>> Ok, it took a while, but I think I have this thing somewhat bisected.
>>>
>>> Starting at commit 4cc4d24efce4672f9b0e7fa27963770ae602998f, I see
>>> hard-drive
>>> issues. Commits right before this (in git bisect) crash in the
>>> networking code
>>> quite often, but the hard-drive logic seems to work at least.
>>>
>>> In later builds (ie, -rc3), the crashes and warnings are different, but
>>> they have something to do with the file system. It's difficult to bisect
>>> it any better because of all the instability...

I tried today's kernel (39-rc4+) and it seems much more stable on my
system.  So, I think the problem must be fixed.  It appears it was not
fixed in the plain 39-rc4, for what that's worth.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: WARNING at libata-core.c:5015 in 2.6.39-rc3-wl+, then lockup. (bisected)

[Tejun Heo]

Hello,

On Wed, Apr 20, 2011 at 07:03:18PM -0700, Ben Greear wrote:
> I tried today's kernel (39-rc4+) and it seems much more stable on my
> system.  So, I think the problem must be fixed.  It appears it was not
> fixed in the plain 39-rc4, for what that's worth.

Hmmm... interesting.  I don't know of any changes which could have
affected that but then again I've been half offline for the last three
weeks.  Can you please try to boot earlier kernel and determine
whether the kernel version difference is actually making the
difference?

Thanks.

-- 
tejun

Re: WARNING at libata-core.c:5015 in 2.6.39-rc3-wl+, then lockup. (bisected)

[Ben Greear]

On 04/21/2011 06:25 AM, Tejun Heo wrote:
> Hello,
>
> On Wed, Apr 20, 2011 at 07:03:18PM -0700, Ben Greear wrote:
>> I tried today's kernel (39-rc4+) and it seems much more stable on my
>> system.  So, I think the problem must be fixed.  It appears it was not
>> fixed in the plain 39-rc4, for what that's worth.
>
> Hmmm... interesting.  I don't know of any changes which could have
> affected that but then again I've been half offline for the last three
> weeks.  Can you please try to boot earlier kernel and determine
> whether the kernel version difference is actually making the
> difference?

I tried the 39-rc4-wl (wireless-testing) kernel that was based off of
39-rc4, and I see hard-drive read errors there, and eventually
crashes.  I didn't try Linus's 39-rc4.

Yesterday's rc4+ kernel ran fine overnight.

I had previously bisected this to a merge in post 2.6.38 code, but
I never found time to figure out what part of the merge was
funky.  In general, from 2.6.38 to very recently, the kernels
have been very unstable on my systems, with multiple networking
crashes and this block level and/or hard-drive stuff causing
trouble, so it's hard to tell exactly when certain bugs
were introduced.

2.6.38 has been stable, as has 2.6.38-wl.

If there is some other specific commit you'd like me to test
I can do so.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com