Hi,
when I insert a CF or SD card from my cameras into the USB card reader,
I get the attached kernel oops. This is reproducible and did not happen
with 2.6.38.
The cards use FAT32.
Regards,
Tino
On Mon, May 02, 2011 at 08:49:45 +0200, Tino Keitel wrote:
> Hi,
>
> when I insert a CF or SD card from my cameras into the USB card reader,
> I get the attached kernel oops. This is reproducible and did not happen
> with 2.6.38.
Forgot to mention: the bug occurs with 2.6.39-rc5.
Regards,
Tino
Tino Keitel <[email protected]> writes:
> On Mon, May 02, 2011 at 08:49:45 +0200, Tino Keitel wrote:
>> Hi,
>>
>> when I insert a CF or SD card from my cameras into the USB card reader,
>> I get the attached kernel oops. This is reproducible and did not happen
>> with 2.6.38.
>
> Forgot to mention: the bug occurs with 2.6.39-rc5.
There is no related change in fs/fat after 2.6.38. So, the cause would
be other area. Anyway, I'll see detail a bit.
Thanks.
--
OGAWA Hirofumi <[email protected]>
OGAWA Hirofumi <[email protected]> writes:
> Tino Keitel <[email protected]> writes:
>
>> On Mon, May 02, 2011 at 08:49:45 +0200, Tino Keitel wrote:
>>> Hi,
>>>
>>> when I insert a CF or SD card from my cameras into the USB card reader,
>>> I get the attached kernel oops. This is reproducible and did not happen
>>> with 2.6.38.
>>
>> Forgot to mention: the bug occurs with 2.6.39-rc5.
>
> There is no related change in fs/fat after 2.6.38. So, the cause would
> be other area. Anyway, I'll see detail a bit.
BTW, is this reproducible? And could you send .config both of 2.6.38 and
2.6.39-rc5?
Page fault is in allocated area by module load, it sounds like
strange. Um...
Thanks.
--
OGAWA Hirofumi <[email protected]>
On Tue, May 03, 2011 at 00:12:33 +0900, OGAWA Hirofumi wrote:
> OGAWA Hirofumi <[email protected]> writes:
>
> > Tino Keitel <[email protected]> writes:
> >
> >> On Mon, May 02, 2011 at 08:49:45 +0200, Tino Keitel wrote:
> >>> Hi,
> >>>
> >>> when I insert a CF or SD card from my cameras into the USB card reader,
> >>> I get the attached kernel oops. This is reproducible and did not happen
> >>> with 2.6.38.
> >>
> >> Forgot to mention: the bug occurs with 2.6.39-rc5.
> >
> > There is no related change in fs/fat after 2.6.38. So, the cause would
> > be other area. Anyway, I'll see detail a bit.
>
> BTW, is this reproducible? And could you send .config both of 2.6.38 and
> 2.6.39-rc5?
Yes, it is reproducible. It happens with a CF card from a Canon DSLR as
well as with a SD card from a little Fuji cam. Configs are attached.
Regards,
Tino
Tino Keitel <[email protected]> writes:
> On Tue, May 03, 2011 at 00:12:33 +0900, OGAWA Hirofumi wrote:
>> OGAWA Hirofumi <[email protected]> writes:
>>
>> > Tino Keitel <[email protected]> writes:
>> >
>> >> On Mon, May 02, 2011 at 08:49:45 +0200, Tino Keitel wrote:
>> >>> Hi,
>> >>>
>> >>> when I insert a CF or SD card from my cameras into the USB card reader,
>> >>> I get the attached kernel oops. This is reproducible and did not happen
>> >>> with 2.6.38.
>> >>
>> >> Forgot to mention: the bug occurs with 2.6.39-rc5.
>> >
>> > There is no related change in fs/fat after 2.6.38. So, the cause would
>> > be other area. Anyway, I'll see detail a bit.
>>
>> BTW, is this reproducible? And could you send .config both of 2.6.38 and
>> 2.6.39-rc5?
>
> Yes, it is reproducible. It happens with a CF card from a Canon DSLR as
> well as with a SD card from a little Fuji cam. Configs are attached.
.config didn't have interest part for now. Could you send another oops,
and vfat.ko, fat.ko? I'd like to see more detail by assembler, current
oops is unclear...
And if possible, git bisect is appreciate.
Thanks.
--
OGAWA Hirofumi <[email protected]>
On Tue, May 03, 2011 at 03:46:31 +0900, OGAWA Hirofumi wrote:
> Tino Keitel <[email protected]> writes:
>
> > On Tue, May 03, 2011 at 00:12:33 +0900, OGAWA Hirofumi wrote:
> >> OGAWA Hirofumi <[email protected]> writes:
> >>
> >> > Tino Keitel <[email protected]> writes:
> >> >
> >> >> On Mon, May 02, 2011 at 08:49:45 +0200, Tino Keitel wrote:
> >> >>> Hi,
> >> >>>
> >> >>> when I insert a CF or SD card from my cameras into the USB card reader,
> >> >>> I get the attached kernel oops. This is reproducible and did not happen
> >> >>> with 2.6.38.
> >> >>
> >> >> Forgot to mention: the bug occurs with 2.6.39-rc5.
> >> >
> >> > There is no related change in fs/fat after 2.6.38. So, the cause would
> >> > be other area. Anyway, I'll see detail a bit.
> >>
> >> BTW, is this reproducible? And could you send .config both of 2.6.38 and
> >> 2.6.39-rc5?
> >
> > Yes, it is reproducible. It happens with a CF card from a Canon DSLR as
> > well as with a SD card from a little Fuji cam. Configs are attached.
>
> .config didn't have interest part for now. Could you send another oops,
> and vfat.ko, fat.ko? I'd like to see more detail by assembler, current
> oops is unclear...
Another Oops, this time with the SD card, and the modules are attached.
> And if possible, git bisect is appreciate.
Lack of spare time currently, sorry.
Regards,
Tino
On Mon, May 02, 2011 at 22:33:27 +0200, Tino Keitel wrote:
> On Tue, May 03, 2011 at 03:46:31 +0900, OGAWA Hirofumi wrote:
> > Tino Keitel <[email protected]> writes:
> >
> > > On Tue, May 03, 2011 at 00:12:33 +0900, OGAWA Hirofumi wrote:
> > >> OGAWA Hirofumi <[email protected]> writes:
> > >>
> > >> > Tino Keitel <[email protected]> writes:
> > >> >
> > >> >> On Mon, May 02, 2011 at 08:49:45 +0200, Tino Keitel wrote:
> > >> >>> Hi,
> > >> >>>
> > >> >>> when I insert a CF or SD card from my cameras into the USB card reader,
> > >> >>> I get the attached kernel oops. This is reproducible and did not happen
> > >> >>> with 2.6.38.
> > >> >>
> > >> >> Forgot to mention: the bug occurs with 2.6.39-rc5.
> > >> >
> > >> > There is no related change in fs/fat after 2.6.38. So, the cause would
> > >> > be other area. Anyway, I'll see detail a bit.
> > >>
> > >> BTW, is this reproducible? And could you send .config both of 2.6.38 and
> > >> 2.6.39-rc5?
> > >
> > > Yes, it is reproducible. It happens with a CF card from a Canon DSLR as
> > > well as with a SD card from a little Fuji cam. Configs are attached.
> >
> > .config didn't have interest part for now. Could you send another oops,
> > and vfat.ko, fat.ko? I'd like to see more detail by assembler, current
> > oops is unclear...
>
> Another Oops, this time with the SD card, and the modules are attached.
Forgot the attachemnts, as usual.
Tino Keitel <[email protected]> writes:
>> > Yes, it is reproducible. It happens with a CF card from a Canon DSLR as
>> > well as with a SD card from a little Fuji cam. Configs are attached.
>>
>> .config didn't have interest part for now. Could you send another oops,
>> and vfat.ko, fat.ko? I'd like to see more detail by assembler, current
>> oops is unclear...
>
> Another Oops, this time with the SD card, and the modules are attached.
>
>> And if possible, git bisect is appreciate.
>
> Lack of spare time currently, sorry.
OK. Thanks for your help.
Thanks.
--
OGAWA Hirofumi <[email protected]>
OGAWA Hirofumi <[email protected]> writes:
> Tino Keitel <[email protected]> writes:
>
>>> > Yes, it is reproducible. It happens with a CF card from a Canon DSLR as
>>> > well as with a SD card from a little Fuji cam. Configs are attached.
>>>
>>> .config didn't have interest part for now. Could you send another oops,
>>> and vfat.ko, fat.ko? I'd like to see more detail by assembler, current
>>> oops is unclear...
>>
>> Another Oops, this time with the SD card, and the modules are attached.
>>
>>> And if possible, git bisect is appreciate.
>>
>> Lack of spare time currently, sorry.
>
> OK. Thanks for your help.
It seems to be interesting exception.
before relocation (from fat.ko)
8656: 74 51 je 86a9 <fat_build_inode+0x2e9>
8658: 49 c7 c6 00 00 00 00 mov $0x0,%r14
865f: b2 b6 mov $0xb6,%dl
8661: 80 3d 00 00 00 00 00 cmpb $0x0,0x0(%rip) <-- exception
8668: 74 3f je 86a9 <fat_build_inode+0x2e9>
866a: 49 8d 44 24 08 lea 0x8(%r12),%rax
after relocation (from oops)
20: 74 51 je 73 <a+0x73>
22: 49 c7 c6 d8 91 13 a0 mov $0xffffffffa01391d8,%r14
29: b2 b6 mov $0xb6,%dl
2b: 3d fc 9b 00 00 cmp $0x9bfc,%eax
30: 00 74 3f 49 add %dh,0x49(%rdi,%rdi,1)
34: 8d 44 24 08 lea 0x8(%rsp),%eax
relocation info would be this
0x0000000000006883 X86_64_32S 000000000000000000 +253 .rodata.str1.1
Although I'm not sure at all for now, I'm guessing something wrong
happened around relocation.
Thanks.
--
OGAWA Hirofumi <[email protected]>
OGAWA Hirofumi <[email protected]> writes:
> OGAWA Hirofumi <[email protected]> writes:
>
>> Tino Keitel <[email protected]> writes:
>>
>>>> > Yes, it is reproducible. It happens with a CF card from a Canon DSLR as
>>>> > well as with a SD card from a little Fuji cam. Configs are attached.
>>>>
>>>> .config didn't have interest part for now. Could you send another oops,
>>>> and vfat.ko, fat.ko? I'd like to see more detail by assembler, current
>>>> oops is unclear...
>>>
>>> Another Oops, this time with the SD card, and the modules are attached.
>>>
>>>> And if possible, git bisect is appreciate.
>>>
>>> Lack of spare time currently, sorry.
>>
>> OK. Thanks for your help.
>
> It seems to be interesting exception.
>
> before relocation (from fat.ko)
> 8656: 74 51 je 86a9 <fat_build_inode+0x2e9>
> 8658: 49 c7 c6 00 00 00 00 mov $0x0,%r14
> 865f: b2 b6 mov $0xb6,%dl
> 8661: 80 3d 00 00 00 00 00 cmpb $0x0,0x0(%rip) <-- exception
> 8668: 74 3f je 86a9 <fat_build_inode+0x2e9>
> 866a: 49 8d 44 24 08 lea 0x8(%r12),%rax
>
> after relocation (from oops)
>
> 20: 74 51 je 73 <a+0x73>
> 22: 49 c7 c6 d8 91 13 a0 mov $0xffffffffa01391d8,%r14
> 29: b2 b6 mov $0xb6,%dl
> 2b: 3d fc 9b 00 00 cmp $0x9bfc,%eax
> 30: 00 74 3f 49 add %dh,0x49(%rdi,%rdi,1)
> 34: 8d 44 24 08 lea 0x8(%rsp),%eax
>
> relocation info would be this
> 0x0000000000006883 X86_64_32S 000000000000000000 +253 .rodata.str1.1
>
> Although I'm not sure at all for now, I'm guessing something wrong
> happened around relocation.
BTW, rebuilding from scratch make something difference?
Thanks.
--
OGAWA Hirofumi <[email protected]>
OGAWA Hirofumi <[email protected]> writes:
> OGAWA Hirofumi <[email protected]> writes:
>
>> Tino Keitel <[email protected]> writes:
>>
>>>> > Yes, it is reproducible. It happens with a CF card from a Canon DSLR as
>>>> > well as with a SD card from a little Fuji cam. Configs are attached.
>>>>
>>>> .config didn't have interest part for now. Could you send another oops,
>>>> and vfat.ko, fat.ko? I'd like to see more detail by assembler, current
>>>> oops is unclear...
>>>
>>> Another Oops, this time with the SD card, and the modules are attached.
>>>
>>>> And if possible, git bisect is appreciate.
>>>
>>> Lack of spare time currently, sorry.
>>
>> OK. Thanks for your help.
>
> It seems to be interesting exception.
>
> before relocation (from fat.ko)
> 8656: 74 51 je 86a9 <fat_build_inode+0x2e9>
> 8658: 49 c7 c6 00 00 00 00 mov $0x0,%r14
> 865f: b2 b6 mov $0xb6,%dl
> 8661: 80 3d 00 00 00 00 00 cmpb $0x0,0x0(%rip) <-- exception
> 8668: 74 3f je 86a9 <fat_build_inode+0x2e9>
> 866a: 49 8d 44 24 08 lea 0x8(%r12),%rax
>
> after relocation (from oops)
>
> 20: 74 51 je 73 <a+0x73>
> 22: 49 c7 c6 d8 91 13 a0 mov $0xffffffffa01391d8,%r14
> 29: b2 b6 mov $0xb6,%dl
> 2b: 3d fc 9b 00 00 cmp $0x9bfc,%eax
> 30: 00 74 3f 49 add %dh,0x49(%rdi,%rdi,1)
> 34: 8d 44 24 08 lea 0x8(%rsp),%eax
>
> relocation info would be this
> 0x0000000000006883 X86_64_32S 000000000000000000 +253 .rodata.str1.1
Whoops, wrong info.
relocation info should be this
0x0000000000008663 X86_64_PC32 0x000000000000927c -5 .LC55
--
OGAWA Hirofumi <[email protected]>
OGAWA Hirofumi <[email protected]> writes:
>> It seems to be interesting exception.
>>
>> before relocation (from fat.ko)
>> 8656: 74 51 je 86a9 <fat_build_inode+0x2e9>
>> 8658: 49 c7 c6 00 00 00 00 mov $0x0,%r14
>> 865f: b2 b6 mov $0xb6,%dl
>> 8661: 80 3d 00 00 00 00 00 cmpb $0x0,0x0(%rip) <-- exception
>> 8668: 74 3f je 86a9 <fat_build_inode+0x2e9>
>> 866a: 49 8d 44 24 08 lea 0x8(%r12),%rax
>>
>> after relocation (from oops)
>>
>> 20: 74 51 je 73 <a+0x73>
>> 22: 49 c7 c6 d8 91 13 a0 mov $0xffffffffa01391d8,%r14
>> 29: b2 b6 mov $0xb6,%dl
>> 2b: 3d fc 9b 00 00 cmp $0x9bfc,%eax
>> 30: 00 74 3f 49 add %dh,0x49(%rdi,%rdi,1)
>> 34: 8d 44 24 08 lea 0x8(%rsp),%eax
>>
> relocation info should be this
>
> 0x0000000000008663 X86_64_PC32 0x000000000000927c -5 .LC55
Hm. It seems to be 0x80 was gone somehow. If I added 0x80 at 0x8661, it
seems to be sane code.
20: 74 51 je 73 <a+0x73>
22: 49 c7 c6 d8 91 13 a0 mov $0xffffffffa01391d8,%r14
29: b2 b6 mov $0xb6,%dl
2b: 80 3d fc 9b 00 00 00 cmpb $0x0,0x9bfc(%rip) <- here is 0x8661
32: 74 3f je 73 <a+0x73>
34: 49 8d 44 24 08 lea 0x8(%r12),%rax
I have no idea how this happened for now. This would be needed to trace
when happened.
At first, it would be module load time. If you had time to debug and
trace, I may be able to help to debug it.
Cc: to module maintainer.
Any idea?
Thanks.
--
OGAWA Hirofumi <[email protected]>
OGAWA Hirofumi <[email protected]> writes:
> OGAWA Hirofumi <[email protected]> writes:
>
>>> It seems to be interesting exception.
>>>
>>> before relocation (from fat.ko)
>>> 8656: 74 51 je 86a9 <fat_build_inode+0x2e9>
>>> 8658: 49 c7 c6 00 00 00 00 mov $0x0,%r14
>>> 865f: b2 b6 mov $0xb6,%dl
>>> 8661: 80 3d 00 00 00 00 00 cmpb $0x0,0x0(%rip) <-- exception
>>> 8668: 74 3f je 86a9 <fat_build_inode+0x2e9>
>>> 866a: 49 8d 44 24 08 lea 0x8(%r12),%rax
>>>
>>> after relocation (from oops)
>>>
>>> 20: 74 51 je 73 <a+0x73>
>>> 22: 49 c7 c6 d8 91 13 a0 mov $0xffffffffa01391d8,%r14
>>> 29: b2 b6 mov $0xb6,%dl
>>> 2b: 3d fc 9b 00 00 cmp $0x9bfc,%eax
>>> 30: 00 74 3f 49 add %dh,0x49(%rdi,%rdi,1)
>>> 34: 8d 44 24 08 lea 0x8(%rsp),%eax
>>>
>> relocation info should be this
>>
>> 0x0000000000008663 X86_64_PC32 0x000000000000927c -5 .LC55
>
> Hm. It seems to be 0x80 was gone somehow. If I added 0x80 at 0x8661, it
> seems to be sane code.
>
> 20: 74 51 je 73 <a+0x73>
> 22: 49 c7 c6 d8 91 13 a0 mov $0xffffffffa01391d8,%r14
> 29: b2 b6 mov $0xb6,%dl
> 2b: 80 3d fc 9b 00 00 00 cmpb $0x0,0x9bfc(%rip) <- here is 0x8661
> 32: 74 3f je 73 <a+0x73>
> 34: 49 8d 44 24 08 lea 0x8(%r12),%rax
Code: fd ff ff 0f 1f 80 00 00 00 00 83 ca 01 89 93 10 02 00 00 ba ff 01 00 00 41 f6 85 96 00 00 00 02 74 51 49 c7 c6 d8 91 13 a0 b2 b6 3d fc 9b 00 00 00 74 3f 49 8d 44 24 08 48 89 44 24 08 eb 18
Oops's Code: was really this? This Code: is missing only <80>, I can't
see why there is no <xx> byte. Even if code was screwed up, I think
Code: should show the <xx>.
> I have no idea how this happened for now. This would be needed to trace
> when happened.
>
> At first, it would be module load time. If you had time to debug and
> trace, I may be able to help to debug it.
>
> Cc: to module maintainer.
>
> Any idea?
>
> Thanks.
--
OGAWA Hirofumi <[email protected]>
On Tue, May 03, 2011 at 09:44:08 +0900, OGAWA Hirofumi wrote:
[...]
> BTW, rebuilding from scratch make something difference?
Hi,
I upgraded to current git (5933f2ae353a93b1d3b501bc63c925531849bbc7),
and did a git clean -dfx. The rebuilt kernel now does not Oops anymore,
with both the CF and the SD card. Could this be a glitch in the
Makefile dependencies?
Regards,
Tino
Tino Keitel <[email protected]> writes:
> On Tue, May 03, 2011 at 09:44:08 +0900, OGAWA Hirofumi wrote:
>
> [...]
>
>> BTW, rebuilding from scratch make something difference?
>
> Hi,
Hi,
> I upgraded to current git (5933f2ae353a93b1d3b501bc63c925531849bbc7),
> and did a git clean -dfx. The rebuilt kernel now does not Oops anymore,
> with both the CF and the SD card. Could this be a glitch in the
> Makefile dependencies?
It's hard to say, the behavior is too strange, but I guess there is
possibility (to spot the cause, I think we have to checking binary. It
would need long time even if we want to do.).
If you want to check slightly, you can checkout previous commitid, then
rebuild and test. If previous one worked well, it can be Makefile
dependencies (or something in build-toolchain if you upgraded after
test).
Thanks.
--
OGAWA Hirofumi <[email protected]>
On Tue, 03 May 2011 11:34:11 +0900, OGAWA Hirofumi <[email protected]> wrote:
> > Hm. It seems to be 0x80 was gone somehow. If I added 0x80 at 0x8661, it
> > seems to be sane code.
> >
> > 20: 74 51 je 73 <a+0x73>
> > 22: 49 c7 c6 d8 91 13 a0 mov $0xffffffffa01391d8,%r14
> > 29: b2 b6 mov $0xb6,%dl
> > 2b: 80 3d fc 9b 00 00 00 cmpb $0x0,0x9bfc(%rip) <- here is 0x8661
> > 32: 74 3f je 73 <a+0x73>
> > 34: 49 8d 44 24 08 lea 0x8(%r12),%rax
>
> Code: fd ff ff 0f 1f 80 00 00 00 00 83 ca 01 89 93 10 02 00 00 ba ff
> 01 00 00 41 f6 85 96 00 00 00 02 74 51 49 c7 c6 d8 91 13 a0 b2 b6 3d
> fc 9b 00 00 00 74 3f 49 8d 44 24 08 48 89 44 24 08 eb 18
How strange, but if this can't be reproduced with a rebuilt kernel I'm
tempted to put it down to corruption in the module somehow...
Thanks,
Rusty.
Rusty Russell <[email protected]> writes:
> On Tue, 03 May 2011 11:34:11 +0900, OGAWA Hirofumi
> <[email protected]> wrote:
>> > Hm. It seems to be 0x80 was gone somehow. If I added 0x80 at 0x8661, it
>> > seems to be sane code.
>> >
>> > 20: 74 51 je 73 <a+0x73>
>> > 22: 49 c7 c6 d8 91 13 a0 mov $0xffffffffa01391d8,%r14
>> > 29: b2 b6 mov $0xb6,%dl
>> > 2b: 80 3d fc 9b 00 00 00 cmpb $0x0,0x9bfc(%rip) <- here is
>> > 0x8661
>> > 32: 74 3f je 73 <a+0x73>
>> > 34: 49 8d 44 24 08 lea 0x8(%r12),%rax
>>
>> Code: fd ff ff 0f 1f 80 00 00 00 00 83 ca 01 89 93 10 02 00 00 ba ff
>> 01 00 00 41 f6 85 96 00 00 00 02 74 51 49 c7 c6 d8 91 13 a0 b2 b6 3d
>> fc 9b 00 00 00 74 3f 49 8d 44 24 08 48 89 44 24 08 eb 18
>
> How strange, but if this can't be reproduced with a rebuilt kernel I'm
> tempted to put it down to corruption in the module somehow...
I just bridged the bug report, so not pretty sure though. It sounds like
to be fixed by rebuilding kernel.
Thanks.
--
OGAWA Hirofumi <[email protected]>