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

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

[Tino Keitel]

[-- Attachment #1: Type: text/plain, Size: 200 bytes --]

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


[-- Attachment #2: oop --]
[-- Type: text/plain, Size: 4996 bytes --]

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

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

[Tino Keitel]

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

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

[OGAWA Hirofumi]

Tino Keitel <tino.keitel@tikei.de> 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 <hirofumi@mail.parknet.co.jp>

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

[OGAWA Hirofumi]

OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> writes:

> Tino Keitel <tino.keitel@tikei.de> 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 <hirofumi@mail.parknet.co.jp>

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

[Tino Keitel]

[-- Attachment #1: Type: text/plain, Size: 866 bytes --]

On Tue, May 03, 2011 at 00:12:33 +0900, OGAWA Hirofumi wrote:
> OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> writes:
> 
> > Tino Keitel <tino.keitel@tikei.de> 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

[-- Attachment #2: config-2.6.38.2-00001-g5e8a92a-dirty.gz --]
[-- Type: application/octet-stream, Size: 15485 bytes --]

[-- Attachment #3: config-2.6.39-rc5-00001-g1beb336-dirty.gz --]
[-- Type: application/octet-stream, Size: 15767 bytes --]

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

[OGAWA Hirofumi]

Tino Keitel <tino.keitel@gmx.de> writes:

> On Tue, May 03, 2011 at 00:12:33 +0900, OGAWA Hirofumi wrote:
>> OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> writes:
>> 
>> > Tino Keitel <tino.keitel@tikei.de> 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 <hirofumi@mail.parknet.co.jp>

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

[Tino Keitel]

On Tue, May 03, 2011 at 03:46:31 +0900, OGAWA Hirofumi wrote:
> Tino Keitel <tino.keitel@gmx.de> writes:
> 
> > On Tue, May 03, 2011 at 00:12:33 +0900, OGAWA Hirofumi wrote:
> >> OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> writes:
> >> 
> >> > Tino Keitel <tino.keitel@tikei.de> 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

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

[Tino Keitel]

[-- Attachment #1: Type: text/plain, Size: 1428 bytes --]

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 <tino.keitel@gmx.de> writes:
> > 
> > > On Tue, May 03, 2011 at 00:12:33 +0900, OGAWA Hirofumi wrote:
> > >> OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> writes:
> > >> 
> > >> > Tino Keitel <tino.keitel@tikei.de> 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.

[-- Attachment #2: vfat.ko --]
[-- Type: application/octet-stream, Size: 20800 bytes --]

[-- Attachment #3: fat.ko --]
[-- Type: application/octet-stream, Size: 89880 bytes --]

[-- Attachment #4: Oops --]
[-- Type: text/plain, Size: 4800 bytes --]

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

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

[OGAWA Hirofumi]

Tino Keitel <tino.keitel@tikei.de> 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 <hirofumi@mail.parknet.co.jp>

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

[OGAWA Hirofumi]

OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> writes:

> Tino Keitel <tino.keitel@tikei.de> 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 <hirofumi@mail.parknet.co.jp>

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

[OGAWA Hirofumi]

OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> writes:

> OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> writes:
>
>> Tino Keitel <tino.keitel@tikei.de> 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 <hirofumi@mail.parknet.co.jp>

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

[OGAWA Hirofumi]

OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> writes:

> OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> writes:
>
>> Tino Keitel <tino.keitel@tikei.de> 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 <hirofumi@mail.parknet.co.jp>

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

[OGAWA Hirofumi]

OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> 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 <hirofumi@mail.parknet.co.jp>

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

[OGAWA Hirofumi]

OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> writes:

> OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> 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 <hirofumi@mail.parknet.co.jp>

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

[Tino Keitel]

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

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

[OGAWA Hirofumi]

Tino Keitel <tino.keitel@tikei.de> 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 <hirofumi@mail.parknet.co.jp>

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

[Rusty Russell]

On Tue, 03 May 2011 11:34:11 +0900, OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> 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.

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

[OGAWA Hirofumi]

Rusty Russell <rusty@rustcorp.com.au> writes:

> On Tue, 03 May 2011 11:34:11 +0900, OGAWA Hirofumi
> <hirofumi@mail.parknet.co.jp> 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 <hirofumi@mail.parknet.co.jp>