unable to handle kernel paging request when inserting FAT32 formatted flash media

DISCUSSION Tino Keitel 4 participants 18 messages May 2, 2011 – May 9, 2011

Share & tools

Tino Keitel

author

2011-05-02 06:49 UTC #0 lore raw

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

usb 5-1: new full speed USB device number 16 using uhci_hcd usb 5-1: New USB device found, idVendor=05ac, idProduct=8205 usb 5-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 sd 6:0:0:0: [sdb] 32014080 512-byte logical blocks: (16.3 GB/15.2 GiB) sd 6:0:0:0: [sdb] Assuming drive cache: write through
sd 6:0:0:0: [sdb] Assuming drive cache: write through
sdb: sdb1

BUG: unable to handle kernel paging request at ffffffffa0142264
IP: [<ffffffffa0138661>] fat_build_inode+0x2a1/0x4b0 [fat]
PGD 1635067 PUD 1639063 PMD b930d067 PTE 0
Oops: 0000 [#1] SMP 
last sysfs file: /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-5/1-5.2/speed
CPU 1 
Modules linked in: nls_iso8859_1 nls_cp437 vfat fat dvb_usb_vp7045 dvb_usb dvb_core rc_core cpufreq_stats ipv6 loop btusb bluetooth usblp snd_hda_codec_idt arc4 snd_hda_intel snd_hda_codec ecb snd_pcm_oss snd_pcm ath5k ath snd_timer mac80211 snd_page_alloc sky2 evdev cfg80211 ata_piix [last unloaded: rc_core]

Pid: 22745, comm: gvfs-gdu-volume Not tainted 2.6.39-rc5-00001-g1beb336-dirty #22 Apple Inc. Macmini2,1/Mac-F4208EAA

RIP: 0010:[<ffffffffa0138661>]  [<ffffffffa0138661>] fat_build_inode+0x2a1/0x4b0 [fat]
RSP: 0018:ffff88000e4dbbd8  EFLAGS: 00010202
RAX: 000000004dbaff8f RBX: ffff880053a21848 RCX: 0000000000000012
RDX: 00000000000001b6 RSI: 0000000000000001 RDI: ffffffff81632340
RBP: 000000000001ea64 R08: 0000000000000073 R09: ffffffffa0146dc0
R10: 0000000000000000 R11: 0000000000000004 R12: ffff88001df60c80
R13: ffff88009c4f3000 R14: ffffffffa01391d8 R15: ffff880053a217f8
FS:  00007fac4c9877a0(0000) GS:ffff8800bed00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffa0142264 CR3: 00000000840b3000 CR4: 00000000000006a0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process gvfs-gdu-volume (pid: 22745, threadinfo ffff88000e4da000, task ffff8800b3e647c0)
Stack:
 ffff8800b5e40af0 02ff880097e9b8c0 0000000000000001 ffff880096146cc0
 ffff880087b37400 0000000000000000 0000000000000001 ffff88000e4dbd68
 ffff880042174c80 ffffffffa013e692 ffff88000e4dbce8 ffff88000e4dbde8
Call Trace:
 [<ffffffffa013e692>] ? vfat_lookup+0x82/0x180 [vfat]
 [<ffffffff810ccedc>] ? d_alloc_and_lookup+0x3c/0x90
 [<ffffffff810d907e>] ? d_lookup+0x2e/0x60
 [<ffffffff810cedbb>] ? do_lookup+0xcb/0x2a0
 [<ffffffff810cfabd>] ? path_lookupat+0x15d/0x7f0
 [<ffffffffa013204b>] ? __fat_readdir.clone.14+0x12b/0xc60 [fat]
 [<ffffffff810d017b>] ? do_path_lookup+0x2b/0x90
 [<ffffffff810d02cc>] ? user_path_at+0x5c/0xc0
 [<ffffffff810c7247>] ? cp_new_stat+0xe7/0x100
 [<ffffffff810c70e0>] ? vfs_fstatat+0x40/0x80
 [<ffffffff810c755f>] ? sys_newlstat+0x1f/0x50
 [<ffffffff814a7d15>] ? device_not_available+0x15/0x20
 [<ffffffff814a71fb>] ? system_call_fastpath+0x16/0x1b
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 
RIP  [<ffffffffa0138661>] fat_build_inode+0x2a1/0x4b0 [fat]
 RSP <ffff88000e4dbbd8>
CR2: ffffffffa0142264
---[ end trace ea722c87b144bb1d ]---
------------[ cut here ]------------
WARNING: at kernel/exit.c:910 do_exit+0x715/0x7b0()
Hardware name: Macmini2,1
Modules linked in: nls_iso8859_1 nls_cp437 vfat fat dvb_usb_vp7045 dvb_usb dvb_core rc_core cpufreq_stats ipv6 loop btusb bluetooth usblp snd_hda_codec_idt arc4 snd_hda_intel snd_hda_codec ecb snd_pcm_oss snd_pcm ath5k ath snd_timer mac80211 snd_page_alloc sky2 evdev cfg80211 ata_piix [last unloaded: rc_core]
Pid: 22745, comm: gvfs-gdu-volume Tainted: G      D     2.6.39-rc5-00001-g1beb336-dirty #22
Call Trace:
 [<ffffffff8103a01b>] ? warn_slowpath_common+0x7b/0xc0
 [<ffffffff8103dcf5>] ? do_exit+0x715/0x7b0
 [<ffffffff814a40d2>] ? printk+0x40/0x46
 [<ffffffff8103ba00>] ? kmsg_dump+0x40/0xf0
 [<ffffffff81005cca>] ? oops_end+0x9a/0xe0
 [<ffffffff81022edd>] ? no_context+0xfd/0x270
 [<ffffffff81023856>] ? do_page_fault+0x376/0x410
 [<ffffffffa0130b96>] ? fat_parse_long+0x1d6/0x280 [fat]
 [<ffffffffa0131ebb>] ? fat_search_long+0x7fb/0x860 [fat]
 [<ffffffff814a6e1f>] ? page_fault+0x1f/0x30
 [<ffffffffa0138661>] ? fat_build_inode+0x2a1/0x4b0 [fat]
 [<ffffffffa0138490>] ? fat_build_inode+0xd0/0x4b0 [fat]
 [<ffffffffa013e692>] ? vfat_lookup+0x82/0x180 [vfat]
 [<ffffffff810ccedc>] ? d_alloc_and_lookup+0x3c/0x90
 [<ffffffff810d907e>] ? d_lookup+0x2e/0x60
 [<ffffffff810cedbb>] ? do_lookup+0xcb/0x2a0
 [<ffffffff810cfabd>] ? path_lookupat+0x15d/0x7f0
 [<ffffffffa013204b>] ? __fat_readdir.clone.14+0x12b/0xc60 [fat]
 [<ffffffff810d017b>] ? do_path_lookup+0x2b/0x90
 [<ffffffff810d02cc>] ? user_path_at+0x5c/0xc0
 [<ffffffff810c7247>] ? cp_new_stat+0xe7/0x100
 [<ffffffff810c70e0>] ? vfs_fstatat+0x40/0x80
 [<ffffffff810c755f>] ? sys_newlstat+0x1f/0x50
 [<ffffffff814a7d15>] ? device_not_available+0x15/0x20
 [<ffffffff814a71fb>] ? system_call_fastpath+0x16/0x1b
---[ end trace ea722c87b144bb1e ]---

Tino Keitel

author

2011-05-02 06:55 UTC #1 lore raw

Quoted 5 lines · Tino Keitel

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

OGAWA Hirofumi

2011-05-02 14:34 UTC #2 lore raw

Quoted 8 lines · Tino Keitel

Quoted 5 lines · Tino Keitel
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.

Signature · 1 line

OGAWA Hirofumi <[email protected]>

OGAWA Hirofumi

2011-05-02 15:12 UTC #3 lore raw

Quoted 5 lines · OGAWA Hirofumi

Quoted 3 lines · Tino Keitel
Quoted 2 lines · Tino Keitel
Hi,

Quoted 8 lines

Quoted 5 lines
Quoted 3 lines
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.

Signature · 1 line

OGAWA Hirofumi <[email protected]>

Tino Keitel

2011-05-02 17:01 UTC #4 lore raw

Quoted 11 lines · OGAWA Hirofumi

Quoted 9 lines · OGAWA Hirofumi
Quoted 7 lines · Tino Keitel
Quoted 5 lines · Tino Keitel
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.

Quoted 7 lines

Quoted 4 lines
Quoted 1 line
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

OGAWA Hirofumi

2011-05-02 18:46 UTC #5 lore raw

Quoted 14 lines · Tino Keitel

Quoted 13 lines · OGAWA Hirofumi
Quoted 11 lines · OGAWA Hirofumi
Quoted 8 lines · Tino Keitel
Quoted 5 lines · Tino Keitel
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.

Quoted 8 lines

Quoted 5 lines
Quoted 2 lines
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.

Signature · 1 line

OGAWA Hirofumi <[email protected]>

Tino Keitel

author

2011-05-02 20:33 UTC #6 lore raw

Quoted 22 lines · OGAWA Hirofumi

Quoted 20 lines · Tino Keitel
Quoted 18 lines · OGAWA Hirofumi
Quoted 5 lines · OGAWA Hirofumi
Quoted 3 lines · Tino Keitel
Quoted 2 lines · Tino Keitel
Hi,
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
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?

Quoted 6 lines

Quoted 2 lines
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.

Quoted 1 line

And if possible, git bisect is appreciate.

Lack of spare time currently, sorry.

Regards,
Tino

Tino Keitel

author

2011-05-02 20:34 UTC #7 lore raw

Quoted 23 lines · Tino Keitel

Quoted 22 lines · OGAWA Hirofumi
Quoted 20 lines · Tino Keitel
Quoted 18 lines · OGAWA Hirofumi
Quoted 5 lines · OGAWA Hirofumi
Quoted 3 lines · Tino Keitel
Quoted 2 lines · Tino Keitel
Hi,
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
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?

Quoted 8 lines

Quoted 6 lines
Quoted 2 lines
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.

sd 6:0:0:1: [sdc] 7744512 512-byte logical blocks: (3.96 GB/3.69 GiB) sd 6:0:0:1: [sdc] Assuming drive cache: write through
sd 6:0:0:1: [sdc] Assuming drive cache: write through
sdc: sdc1

BUG: unable to handle kernel paging request at ffffffffa00b8264
IP: [<ffffffffa00ae661>] fat_build_inode+0x2a1/0x4b0 [fat]
PGD 1635067 PUD 1639063 PMD b8e6b067 PTE 0
Oops: 0000 [#1] SMP 
last sysfs file: /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-5/1-5.2/speed
CPU 1 
Modules linked in: nls_iso8859_1 nls_cp437 vfat fat dvb_usb_vp7045 dvb_usb dvb_core rc_core hidp rfcomm ipv6 loop btusb bluetooth usblp arc4 ecb snd_hda_codec_idt snd_hda_intel ath5k snd_hda_codec ath snd_pcm_oss mac80211 snd_pcm snd_timer snd_page_alloc evdev cfg80211 sky2 ata_piix [last unloaded: rc_core]

Pid: 10615, comm: gvfs-gdu-volume Not tainted 2.6.39-rc5-00001-g1beb336-dirty #22 Apple Inc. Macmini2,1/Mac-F4208EAA

RIP: 0010:[<ffffffffa00ae661>]  [<ffffffffa00ae661>] fat_build_inode+0x2a1/0x4b0 [fat]
RSP: 0018:ffff8800b3509bd8  EFLAGS: 00010202
RAX: 000000004dbf141c RBX: ffff8800029cdad8 RCX: 0000000000000012
RDX: 00000000000001b6 RSI: 0000000000000001 RDI: ffffffff81632340
RBP: 0000000000020002 R08: 0000000000000073 R09: ffffffffa00d9dc0
R10: 0000000000000000 R11: 0000000000000004 R12: ffff8800a7a23040
R13: ffff8800b5aa8000 R14: ffffffffa00af1d8 R15: ffff8800029cda88
FS:  00007fa6e87017a0(0000) GS:ffff8800bed00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffa00b8264 CR3: 00000000b3b80000 CR4: 00000000000006a0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process gvfs-gdu-volume (pid: 10615, threadinfo ffff8800b3508000, task ffff8800b443a780)
Stack:
 ffff880079586c90 02ff8800b9571180 0000000000000001 ffff88007e1ac840
 ffff8800b0f8b800 0000000000000000 0000000000000001 ffff8800b3509d68
 ffff88009e7b9300 ffffffffa00b4692 ffffffff8102ca3d ffff8800b3509de8
Call Trace:
 [<ffffffffa00b4692>] ? vfat_lookup+0x82/0x180 [vfat]
 [<ffffffff8102ca3d>] ? check_preempt_curr+0x6d/0x90
 [<ffffffff810ccedc>] ? d_alloc_and_lookup+0x3c/0x90
 [<ffffffff810d907e>] ? d_lookup+0x2e/0x60
 [<ffffffff810cedbb>] ? do_lookup+0xcb/0x2a0
 [<ffffffff810cfabd>] ? path_lookupat+0x15d/0x7f0
 [<ffffffffa00a804b>] ? __fat_readdir.clone.14+0x12b/0xc60 [fat]
 [<ffffffff810d017b>] ? do_path_lookup+0x2b/0x90
 [<ffffffff810d02cc>] ? user_path_at+0x5c/0xc0
 [<ffffffff810c7247>] ? cp_new_stat+0xe7/0x100
 [<ffffffff810c70e0>] ? vfs_fstatat+0x40/0x80
 [<ffffffff810c755f>] ? sys_newlstat+0x1f/0x50
 [<ffffffff814a71fb>] ? system_call_fastpath+0x16/0x1b
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 f1 0a a0 b2 b6 
 3d fc 9b 00 00 00 74 3f 49 8d 44 24 08 48 89 44 24 08 eb 18 
RIP  [<ffffffffa00ae661>] fat_build_inode+0x2a1/0x4b0 [fat]
 RSP <ffff8800b3509bd8>
CR2: ffffffffa00b8264
---[ end trace f689a453b445475b ]---
------------[ cut here ]------------
WARNING: at kernel/exit.c:910 do_exit+0x715/0x7b0()
Hardware name: Macmini2,1
Modules linked in: nls_iso8859_1 nls_cp437 vfat fat dvb_usb_vp7045 dvb_usb dvb_core rc_core hidp rfcomm ipv6 loop btusb bluetooth usblp arc4 ecb snd_hda_codec_idt snd_hda_intel ath5k snd_hda_codec ath snd_pcm_oss mac80211 snd_pcm snd_timer snd_page_alloc evdev cfg80211 sky2 ata_piix [last unloaded: rc_core]
Pid: 10615, comm: gvfs-gdu-volume Tainted: G      D     2.6.39-rc5-00001-g1beb336-dirty #22
Call Trace:
 [<ffffffff8103a01b>] ? warn_slowpath_common+0x7b/0xc0
 [<ffffffff8103dcf5>] ? do_exit+0x715/0x7b0
 [<ffffffff814a40d2>] ? printk+0x40/0x46
 [<ffffffff8103ba00>] ? kmsg_dump+0x40/0xf0
 [<ffffffff81005cca>] ? oops_end+0x9a/0xe0
 [<ffffffff81022edd>] ? no_context+0xfd/0x270
 [<ffffffff81023856>] ? do_page_fault+0x376/0x410
 [<ffffffffa00a6b96>] ? fat_parse_long+0x1d6/0x280 [fat]
 [<ffffffffa00a7ebb>] ? fat_search_long+0x7fb/0x860 [fat]
 [<ffffffff814a6e1f>] ? page_fault+0x1f/0x30
 [<ffffffffa00ae661>] ? fat_build_inode+0x2a1/0x4b0 [fat]
 [<ffffffffa00ae490>] ? fat_build_inode+0xd0/0x4b0 [fat]
 [<ffffffffa00b4692>] ? vfat_lookup+0x82/0x180 [vfat]
 [<ffffffff8102ca3d>] ? check_preempt_curr+0x6d/0x90
 [<ffffffff810ccedc>] ? d_alloc_and_lookup+0x3c/0x90
 [<ffffffff810d907e>] ? d_lookup+0x2e/0x60
 [<ffffffff810cedbb>] ? do_lookup+0xcb/0x2a0
 [<ffffffff810cfabd>] ? path_lookupat+0x15d/0x7f0
 [<ffffffffa00a804b>] ? __fat_readdir.clone.14+0x12b/0xc60 [fat]
 [<ffffffff810d017b>] ? do_path_lookup+0x2b/0x90
 [<ffffffff810d02cc>] ? user_path_at+0x5c/0xc0
 [<ffffffff810c7247>] ? cp_new_stat+0xe7/0x100
 [<ffffffff810c70e0>] ? vfs_fstatat+0x40/0x80
 [<ffffffff810c755f>] ? sys_newlstat+0x1f/0x50
 [<ffffffff814a71fb>] ? system_call_fastpath+0x16/0x1b
---[ end trace f689a453b445475c ]---

OGAWA Hirofumi

2011-05-02 22:04 UTC #8 lore raw

In reply to Tino Keitel

Quoted 7 lines · Tino Keitel

Quoted 6 lines
Quoted 2 lines
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...

Quoted 5 lines

Another Oops, this time with the SD card, and the modules are attached.
Quoted 1 line
And if possible, git bisect is appreciate.
Lack of spare time currently, sorry.

OK. Thanks for your help.

Thanks.

Signature · 1 line

OGAWA Hirofumi <[email protected]>

OGAWA Hirofumi

2011-05-03 00:41 UTC #9 lore raw

Quoted 9 lines · OGAWA Hirofumi

Quoted 7 lines · Tino Keitel
Quoted 6 lines
Quoted 2 lines
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...

Quoted 7 lines

Quoted 5 lines
Another Oops, this time with the SD card, and the modules are attached.
Quoted 1 line
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.

Signature · 1 line

OGAWA Hirofumi <[email protected]>

OGAWA Hirofumi

2011-05-03 00:44 UTC #10 lore raw

Quoted 38 lines · OGAWA Hirofumi

Quoted 9 lines · OGAWA Hirofumi
Quoted 7 lines · Tino Keitel
Quoted 6 lines
Quoted 2 lines
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...
Quoted 7 lines
Quoted 5 lines
Another Oops, this time with the SD card, and the modules are attached.
Quoted 1 line
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

Quoted 5 lines

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.

Signature · 1 line

OGAWA Hirofumi <[email protected]>

Tino Keitel

author

2011-05-03 20:21 UTC #11 lore raw

On Tue, May 03, 2011 at 09:44:08 +0900, OGAWA Hirofumi wrote:

[...]

Quoted 1 line

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

OGAWA Hirofumi

2011-05-03 21:09 UTC #12 lore raw

Quoted 7 lines · Tino Keitel

On Tue, May 03, 2011 at 09:44:08 +0900, OGAWA Hirofumi wrote:
[...]
Quoted 1 line
BTW, rebuilding from scratch make something difference?
Hi,

Hi,

Quoted 4 lines

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.

Signature · 1 line

OGAWA Hirofumi <[email protected]>

OGAWA Hirofumi

2011-05-03 01:14 UTC #13 lore raw

In reply to OGAWA Hirofumi

Quoted 38 lines · OGAWA Hirofumi

Quoted 9 lines · OGAWA Hirofumi
Quoted 7 lines · Tino Keitel
Quoted 6 lines
Quoted 2 lines
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...
Quoted 7 lines
Quoted 5 lines
Another Oops, this time with the SD card, and the modules are attached.
Quoted 1 line
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

Quoted 2 lines

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

Signature · 1 line

OGAWA Hirofumi <[email protected]>

OGAWA Hirofumi

2011-05-03 01:52 UTC #14 lore raw

Quoted 19 lines · OGAWA Hirofumi

Quoted 10 lines

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

Quoted 9 lines

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

Quoted 3 lines

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.

Signature · 1 line

OGAWA Hirofumi <[email protected]>

OGAWA Hirofumi

2011-05-03 02:34 UTC #15 lore raw

Quoted 28 lines · OGAWA Hirofumi

Quoted 19 lines · OGAWA Hirofumi
Quoted 10 lines
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
Quoted 9 lines
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
Quoted 3 lines
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.

Quoted 6 lines

  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>.

Quoted 11 lines

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.

Signature · 1 line

OGAWA Hirofumi <[email protected]>

Rusty Russell

2011-05-09 02:44 UTC #16 lore raw

Quoted 10 lines · OGAWA Hirofumi

Quoted 9 lines

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

Quoted 3 lines

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.

OGAWA Hirofumi

2011-05-09 03:13 UTC #17 lore raw

Quoted 13 lines · Rusty Russell

Quoted 11 lines · OGAWA Hirofumi

Quoted 10 lines

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

Quoted 6 lines

Quoted 3 lines
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.

Signature · 1 line

OGAWA Hirofumi <[email protected]>