Hi, I just wonder. Is there no problem with endianess.
I mean usually bit field is defined with __BIG_ENDIAN_BITFIELD or
__LITTLE_ENDIAN_BITFIELD. But b_jlist and b_modfied is defined with no
pad.
It seems to be good but i just want to make sure.
Thanks.
2013/5/13 Dmitry Monakhov :
> On Mon, 13
On Mon, 13 May 2013 19:26:34 +0800, Zheng Liu wrote:
> On Mon, May 13, 2013 at 09:53:25AM +, EUNBONG SONG wrote:
> >
> >
> > > Hi all,
> >
> > > First of all I couldn't reproduce this regression in my sand box. So
> > > the following speculation is only my guess. I suspect that the commit
On Mon, May 13, 2013 at 09:53:25AM +, EUNBONG SONG wrote:
>
>
> > Hi all,
>
> > First of all I couldn't reproduce this regression in my sand box. So
> > the following speculation is only my guess. I suspect that the commit
> > (ae4647fb) isn't root cause. It just uncover a potential bug t
> Hi all,
> First of all I couldn't reproduce this regression in my sand box. So
> the following speculation is only my guess. I suspect that the commit
> (ae4647fb) isn't root cause. It just uncover a potential bug that has
> been there for a long time. I look at the code, and found two
> s
On Sun, May 12, 2013 at 07:04:45PM -0700, Tony Luck wrote:
> On Sat, May 11, 2013 at 12:52 AM, Dmitry Monakhov
> wrote:.
> > What was page_size and fsblock size?
>
> CONFIG_IA64_PAGE_SIZE_64KB=y
>
> fsblock size is whatever is the default for SLES11SP2 on ia64 - which
> tool will tell me?
>
>
Hi,
I have some problem to boot with 3.10-rc1. So i will test with
e0fd9affeb64088eff407dfc98bbd3a5c17ea479.
The commit message is as follow.
commit e0fd9affeb64088eff407dfc98bbd3a5c17ea479
Merge: 3d15b79 ea9627c
Author: Linus Torvalds
Date: Wed May 8 15:29:48 2013 -0700
Merge tag 'rdma
> Hi,
> Bitfields are likely to be implemented using read-modify-write semantics.
> Modifications of either b_jlist or b_jmodified must be done under lock
> since they share same uint. I guess this lock is missing somewhere.
Hi, I agree with you. b_jlist and b_jmodified share the same unit.
I t
On Sun, May 12, 2013 at 7:21 PM, EUNBONG SONG wrote:
> Hi, my git bisect result is same yours. And i reported that to community
> yesterday.
Ah. Good to have some confirmation (I was never sure how long to keep
running before deciding that a test was "good". My slowest "bad" test took
about 2.5
> CONFIG_IA64_PAGE_SIZE_64KB=y
> fsblock size is whatever is the default for SLES11SP2 on ia64 - which
> tool will tell me?
> My git bisect finally competed and points the a finger at:
> bisect> git bisect good
> ae4647fb7654676fc44a97e86eb35f9f06b99f66 is first bad commit
> commit ae4647fb765
On Sat, May 11, 2013 at 12:52 AM, Dmitry Monakhov wrote:.
> What was page_size and fsblock size?
CONFIG_IA64_PAGE_SIZE_64KB=y
fsblock size is whatever is the default for SLES11SP2 on ia64 - which
tool will tell me?
My git bisect finally competed and points the a finger at:
bisect> git bisect g
On Fri, 10 May 2013 10:27:58 -0700, Tony Luck wrote:
Non-text part: multipart/mixed
> I think I have the same (or highly similar) thing happening on ia64.
What was page_size and fsblock size?
>
> Similarities: seeing assertions fail for b_transaction
> Differences: I only have ext3 filesystems mo
I think I have the same (or highly similar) thing happening on ia64.
Similarities: seeing assertions fail for b_transaction
Differences: I only have ext3 filesystems mounted, no ext4
See attached trace. I'm pretty certain that the highly unhelpful
bugcheck! 0 [1]
comes from the
J_
> Can you give us the full crash message, (i.e., the panic, the BUG,
> WARN, the registers, etc.), and not the stack trace?
> - Ted
Hi, Ted
Actually i try to find the crash point. And i confirmed crash point is in
__journal_remove_journal_head() function.
I added some debu
13 matches
Mail list logo
