2010-04-02 20:42:23

by Randy Dunlap

[permalink] [raw]
Subject: BUG: physmap modprobe & rmmod

2.6.34-rc2 kernel:

Boot up on a common PC, then: modprobe physmap ; rmmod physmap
and bang.

[ 127.836202] calling init_mtd+0x0/0x88 [mtd] @ 3566
[ 127.841742] initcall init_mtd+0x0/0x88 [mtd] returned 0 after 514 usecs
[ 127.863465] calling physmap_init+0x0/0x49 [physmap] @ 3566
[ 127.869454] physmap-flash.0: failed to claim resource 0
[ 127.874760] initcall physmap_init+0x0/0x49 [physmap] returned 0 after 5450 usecs
[ 150.353495] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
[ 150.354142] IP: [<ffffffff8137c655>] device_pm_remove+0xcb/0xff
[ 150.354142] PGD 6d931067 PUD 6da98067 PMD 0
[ 150.354142] Oops: 0002 [#1] SMP
[ 150.354142] last sysfs file: /sys/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.3/devnum
[ 150.354142] CPU 1
[ 150.354142] Modules linked in: physmap(-) mtd chipreg map_funcs ipt_MASQUERADE iptable_nat nf_nat nfsd sco bridge lockd nfs_acl stp auth_rpcgss llc exportfs bnep l2cap crc16 bluetooth rfkill sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables x_tables ipv6 p4_clockmod freq_table speedstep_lib dm_mirror dm_region_hash dm_log dm_multipath scsi_dh dm_mod kvm uinput snd_intel8x0 joydev snd_ac97_codec ac97_bus snd_seq snd_seq_device usbhid snd_pcm snd_timer led_class snd psmouse iTCO_wdt i2c_i801 rtc_cmos iTCO_vendor_support evdev ppdev parport_pc serio_raw parport sg rtc_core i2c_core rtc_lib pcspkr soundcore snd_page_alloc rng_core button thermal intel_agp thermal_sys agpgart hwmon sr_mod cdrom dcdbas ata_generic pata_acpi ata_piix libata ide_pci_generic ide_core sd_mod scsi_mod crc_t10dif ext3 jbd mbcache uhci_hcd ohci_hcd ssb mmc_core pcmcia pcmcia_core ehci_hcd!
usbcore nls_base [last unloaded: processor]
[ 150.354142]
[ 150.354142] Pid: 3575, comm: rmmod Not tainted 2.6.34-rc2 #2 0HH807/OptiPlex GX620
[ 150.354142] RIP: 0010:[<ffffffff8137c655>] [<ffffffff8137c655>] device_pm_remove+0xcb/0xff
[ 150.354142] RSP: 0018:ffff88006d96de48 EFLAGS: 00010202
[ 150.354142] RAX: ffffffffa02f8960 RBX: ffffffffa02f8880 RCX: 0000000000000000
[ 150.354142] RDX: 0000000000000000 RSI: ffffffff81ab6940 RDI: ffffffff81ab6940
[ 150.354142] RBP: ffff88006d96de58 R08: 0000000000000001 R09: 0000000000000000
[ 150.354142] R10: ffffffff81ab69b0 R11: 0000000000000000 R12: ffffffff81ab5b00
[ 150.354142] R13: 00007ffff41a5f60 R14: 0000000000000000 R15: 0000000000000001
[ 150.354142] FS: 00007f05a3e8c6f0(0000) GS:ffff880005600000(0000) knlGS:0000000000000000
[ 150.354142] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 150.354142] CR2: 0000000000000008 CR3: 000000007b21d000 CR4: 00000000000006e0
[ 150.354142] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 150.354142] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 150.354142] Process rmmod (pid: 3575, threadinfo ffff88006d96c000, task ffff88006daa8000)
[ 150.354142] Stack:
[ 150.354142] ffff88006d96de58 ffffffffa02f8880 ffff88006d96de88 ffffffff8136f54f
[ 150.354142] <0> 0000000000000000 0000000000000000 ffffffffa02f8870 00007ffff41a5f60
[ 150.354142] <0> ffff88006d96dea8 ffffffff813765b5 ffffffffa02f8870 0000000000000000
[ 150.354142] Call Trace:
[ 150.354142] [<ffffffff8136f54f>] device_del+0x59/0x24e
[ 150.354142] [<ffffffff813765b5>] platform_device_del+0x2d/0x89
[ 150.354142] [<ffffffff81376dbf>] platform_device_unregister+0x1d/0x37
[ 150.354142] [<ffffffffa02f8604>] physmap_exit+0x1c/0x38 [physmap]
[ 150.354142] [<ffffffff810b38f2>] sys_delete_module+0x2cd/0x391
[ 150.354142] [<ffffffff814d24a7>] ? lockdep_sys_exit_thunk+0x35/0x67
[ 150.354142] [<ffffffff810dd36a>] ? audit_syscall_entry+0x172/0x1a5
[ 150.354142] [<ffffffff8100c6f2>] system_call_fastpath+0x16/0x1b
[ 150.354142] Code: 33 59 01 e8 c4 49 15 00 48 ff 05 9f 33 59 01 48 8d 83 e0 00 00 00 48 c7 c7 40 69 ab 81 48 8b 8b e0 00 00 00 48 8b 93 e8 00 00 00 <48> 89 51 08 48 89 0a 48 89 83 e8 00 00 00 48 89 83 e0 00 00 00
[ 150.354142] RIP [<ffffffff8137c655>] device_pm_remove+0xcb/0xff
[ 150.354142] RSP <ffff88006d96de48>
[ 150.354142] CR2: 0000000000000008
[ 150.800000] ---[ end trace 9a6eaeb4fd0889df ]---


Full kernel log attached.

---
~Randy


Attachments:
physmap.log (113.79 kB)

2010-04-02 21:47:48

by Randy Dunlap

[permalink] [raw]
Subject: Re: BUG: physmap modprobe & rmmod

On Fri, 2 Apr 2010 13:40:58 -0700 Randy Dunlap wrote:

> 2.6.34-rc2 kernel:
>
> Boot up on a common PC, then: modprobe physmap ; rmmod physmap
> and bang.
>
> [ 127.836202] calling init_mtd+0x0/0x88 [mtd] @ 3566
> [ 127.841742] initcall init_mtd+0x0/0x88 [mtd] returned 0 after 514 usecs
> [ 127.863465] calling physmap_init+0x0/0x49 [physmap] @ 3566
> [ 127.869454] physmap-flash.0: failed to claim resource 0
> [ 127.874760] initcall physmap_init+0x0/0x49 [physmap] returned 0 after 5450 usecs
> [ 150.353495] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
> [ 150.354142] IP: [<ffffffff8137c655>] device_pm_remove+0xcb/0xff
> [ 150.354142] PGD 6d931067 PUD 6da98067 PMD 0
> [ 150.354142] Oops: 0002 [#1] SMP
> [ 150.354142] last sysfs file: /sys/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.3/devnum
> [ 150.354142] CPU 1
> [ 150.354142] Modules linked in: physmap(-) mtd chipreg map_funcs ipt_MASQUERADE iptable_nat nf_nat nfsd sco bridge lockd nfs_acl stp auth_rpcgss llc exportfs bnep l2cap crc16 bluetooth rfkill sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables x_tables ipv6 p4_clockmod freq_table speedstep_lib dm_mirror dm_region_hash dm_log dm_multipath scsi_dh dm_mod kvm uinput snd_intel8x0 joydev snd_ac97_codec ac97_bus snd_seq snd_seq_device usbhid snd_pcm snd_timer led_class snd psmouse iTCO_wdt i2c_i801 rtc_cmos iTCO_vendor_support evdev ppdev parport_pc serio_raw parport sg rtc_core i2c_core rtc_lib pcspkr soundcore snd_page_alloc rng_core button thermal intel_agp thermal_sys agpgart hwmon sr_mod cdrom dcdbas ata_generic pata_acpi ata_piix libata ide_pci_generic ide_core sd_mod scsi_mod crc_t10dif ext3 jbd mbcache uhci_hcd ohci_hcd ssb mmc_core pcmcia pcmcia_core ehci_h!
cd!
> usbcore nls_base [last unloaded: processor]
> [ 150.354142]
> [ 150.354142] Pid: 3575, comm: rmmod Not tainted 2.6.34-rc2 #2 0HH807/OptiPlex GX620
> [ 150.354142] RIP: 0010:[<ffffffff8137c655>] [<ffffffff8137c655>] device_pm_remove+0xcb/0xff
> [ 150.354142] RSP: 0018:ffff88006d96de48 EFLAGS: 00010202
> [ 150.354142] RAX: ffffffffa02f8960 RBX: ffffffffa02f8880 RCX: 0000000000000000
> [ 150.354142] RDX: 0000000000000000 RSI: ffffffff81ab6940 RDI: ffffffff81ab6940
> [ 150.354142] RBP: ffff88006d96de58 R08: 0000000000000001 R09: 0000000000000000
> [ 150.354142] R10: ffffffff81ab69b0 R11: 0000000000000000 R12: ffffffff81ab5b00
> [ 150.354142] R13: 00007ffff41a5f60 R14: 0000000000000000 R15: 0000000000000001
> [ 150.354142] FS: 00007f05a3e8c6f0(0000) GS:ffff880005600000(0000) knlGS:0000000000000000
> [ 150.354142] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 150.354142] CR2: 0000000000000008 CR3: 000000007b21d000 CR4: 00000000000006e0
> [ 150.354142] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 150.354142] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 150.354142] Process rmmod (pid: 3575, threadinfo ffff88006d96c000, task ffff88006daa8000)
> [ 150.354142] Stack:
> [ 150.354142] ffff88006d96de58 ffffffffa02f8880 ffff88006d96de88 ffffffff8136f54f
> [ 150.354142] <0> 0000000000000000 0000000000000000 ffffffffa02f8870 00007ffff41a5f60
> [ 150.354142] <0> ffff88006d96dea8 ffffffff813765b5 ffffffffa02f8870 0000000000000000
> [ 150.354142] Call Trace:
> [ 150.354142] [<ffffffff8136f54f>] device_del+0x59/0x24e
> [ 150.354142] [<ffffffff813765b5>] platform_device_del+0x2d/0x89
> [ 150.354142] [<ffffffff81376dbf>] platform_device_unregister+0x1d/0x37
> [ 150.354142] [<ffffffffa02f8604>] physmap_exit+0x1c/0x38 [physmap]
> [ 150.354142] [<ffffffff810b38f2>] sys_delete_module+0x2cd/0x391
> [ 150.354142] [<ffffffff814d24a7>] ? lockdep_sys_exit_thunk+0x35/0x67
> [ 150.354142] [<ffffffff810dd36a>] ? audit_syscall_entry+0x172/0x1a5
> [ 150.354142] [<ffffffff8100c6f2>] system_call_fastpath+0x16/0x1b
> [ 150.354142] Code: 33 59 01 e8 c4 49 15 00 48 ff 05 9f 33 59 01 48 8d 83 e0 00 00 00 48 c7 c7 40 69 ab 81 48 8b 8b e0 00 00 00 48 8b 93 e8 00 00 00 <48> 89 51 08 48 89 0a 48 89 83 e8 00 00 00 48 89 83 e0 00 00 00
> [ 150.354142] RIP [<ffffffff8137c655>] device_pm_remove+0xcb/0xff
> [ 150.354142] RSP <ffff88006d96de48>
> [ 150.354142] CR2: 0000000000000008
> [ 150.800000] ---[ end trace 9a6eaeb4fd0889df ]---


This is with close to an allmodconfig on x86_64, including:

CONFIG_MTD_PHYSMAP=m
CONFIG_MTD_PHYSMAP_COMPAT=y
CONFIG_MTD_PHYSMAP_START=0x8000000
CONFIG_MTD_PHYSMAP_LEN=0
CONFIG_MTD_PHYSMAP_BANKWIDTH=2

---
~Randy

2010-04-02 22:09:31

by Carl-Daniel Hailfinger

[permalink] [raw]
Subject: Re: BUG: physmap modprobe & rmmod

On 02.04.2010 23:47, Randy Dunlap wrote:
> On Fri, 2 Apr 2010 13:40:58 -0700 Randy Dunlap wrote:
>
>
>> 2.6.34-rc2 kernel:
>>
>> Boot up on a common PC, then: modprobe physmap ; rmmod physmap
>> and bang.
>>
> This is with close to an allmodconfig on x86_64, including:
>
> CONFIG_MTD_PHYSMAP=m
> CONFIG_MTD_PHYSMAP_COMPAT=y
> CONFIG_MTD_PHYSMAP_START=0x8000000
> CONFIG_MTD_PHYSMAP_LEN=0
> CONFIG_MTD_PHYSMAP_BANKWIDTH=2
>

Forgive me if this sounds weird, but I was under the impression that
most people who want to reflash their BIOS on x86 (most prominent
physmap usecase on x86) are using a pure userspace solution with
flashrom <http://www.flashrom.org/> nowadays.

flashrom has the advantage of not needing a kernel recompile if you want
support for new chips/chipsets. flashrom doesn't use MTD and accesses
/dev/mem instead. AFAIK flashrom supports BIOS/EFI/... flashing on all
x86 chipsets which are supported by MTD, and on a few other x86 chipsets
(and network/storage/graphics cards) which are not supported by MTD.

Regards,
Carl-Daniel

2010-04-02 22:17:05

by Hartley Sweeten

[permalink] [raw]
Subject: RE: BUG: physmap modprobe & rmmod

On Friday, April 02, 2010 2:47 PM, Randy Dunlap wrote:
>> 2.6.34-rc2 kernel:
>>
>> Boot up on a common PC, then: modprobe physmap ; rmmod physmap
>> and bang.

[snip]

> This is with close to an allmodconfig on x86_64, including:
>
> CONFIG_MTD_PHYSMAP=m
> CONFIG_MTD_PHYSMAP_COMPAT=y
> CONFIG_MTD_PHYSMAP_START=0x8000000
> CONFIG_MTD_PHYSMAP_LEN=0
> CONFIG_MTD_PHYSMAP_BANKWIDTH=2

That's probably the cause of the BUG.

If your not run-time calling physmap_configure(), your resource will
be created as:

static struct physmap_flash_data physmap_flash_data = {
.width = CONFIG_MTD_PHYSMAP_BANKWIDTH,
};

static struct resource physmap_flash_resource = {
.start = CONFIG_MTD_PHYSMAP_START,
.end = CONFIG_MTD_PHYSMAP_START + CONFIG_MTD_PHYSMAP_LEN - 1,
.flags = IORESOURCE_MEM,
};

In other words:

static struct physmap_flash_data physmap_flash_data = {
.width = 2,
};

static struct resource physmap_flash_resource = {
.start = 0x8000000,
.end = 0x8000000 + 0 - 1,
.flags = IORESOURCE_MEM,
};

I don't think your even getting into the physmap_flash_probe routine.
Your probably getting the BUG after:

platform_device_register(&physmap_flash);

Which eventually gets to platform_device_add which is giving you the
message:

> [ 127.869454] physmap-flash.0: failed to claim resource 0

Try this patch to see if it fixes your BUG.

---

mtd/maps/physmap: catch failure to register MTD_PHYSMAP_COMPAT device

If the default Kconfig values are used with MTD_PHYSMAP_COMPAT you end
up with a IORESOURCE_MEM of 0 size. This causes platform_device_add
to fail during the platform_device_register call.

Catch this failure during the physmap_init.

Signed-off-by: H Hartley Sweeten <[email protected]>

---

diff --git a/drivers/mtd/maps/physmap.c b/drivers/mtd/maps/physmap.c
index d9603f7..426461a 100644
--- a/drivers/mtd/maps/physmap.c
+++ b/drivers/mtd/maps/physmap.c
@@ -264,8 +264,11 @@ static int __init physmap_init(void)

err = platform_driver_register(&physmap_flash_driver);
#ifdef CONFIG_MTD_PHYSMAP_COMPAT
- if (err == 0)
- platform_device_register(&physmap_flash);
+ if (err == 0) {
+ err = platform_device_register(&physmap_flash);
+ if (err)
+ platform_driver_unregister(&physmap_flash_driver);
+ }
#endif

return err;

2010-04-02 22:41:39

by Hartley Sweeten

[permalink] [raw]
Subject: RE: BUG: physmap modprobe & rmmod

On Friday, April 02, 2010 3:16 PM, H Hartley Sweeten wrote:
> On Friday, April 02, 2010 2:47 PM, Randy Dunlap wrote:
>>> 2.6.34-rc2 kernel:
>>>
>>> Boot up on a common PC, then: modprobe physmap ; rmmod physmap
>>> and bang.
>
> [snip]
>
>> This is with close to an allmodconfig on x86_64, including:
>>
>> CONFIG_MTD_PHYSMAP=m
>> CONFIG_MTD_PHYSMAP_COMPAT=y
>> CONFIG_MTD_PHYSMAP_START=0x8000000
>> CONFIG_MTD_PHYSMAP_LEN=0
>> CONFIG_MTD_PHYSMAP_BANKWIDTH=2
>
> That's probably the cause of the BUG.
>
> If your not run-time calling physmap_configure(), your resource will
> be created as:
>
> static struct physmap_flash_data physmap_flash_data = {
> .width = CONFIG_MTD_PHYSMAP_BANKWIDTH,
> };
>
> static struct resource physmap_flash_resource = {
> .start = CONFIG_MTD_PHYSMAP_START,
> .end = CONFIG_MTD_PHYSMAP_START + CONFIG_MTD_PHYSMAP_LEN - 1,
> .flags = IORESOURCE_MEM,
> };
>
> In other words:
>
> static struct physmap_flash_data physmap_flash_data = {
> .width = 2,
> };
>
> static struct resource physmap_flash_resource = {
> .start = 0x8000000,
> .end = 0x8000000 + 0 - 1,
> .flags = IORESOURCE_MEM,
> };

I traced this down to kernel/resource.c. When __request_resource
is finally called, because of the platform_device_register, it ends
up returning a conflict due to:

resource_size_t start = new->start;
resource_size_t end = new->end;
struct resource *tmp, **p;

if (end < start)
return root;

This ends up causing an -EBUSY error code. The patch below should
be correct to fix this.

I changed the commit message a bit.

---

mtd/maps/physmap: catch failure to register MTD_PHYSMAP_COMPAT device

If the default Kconfig values are used with MTD_PHYSMAP_COMPAT you end
up with a resource where end < start. This causes __request_resource to
return a conflict which then returns an -EBUSY error code. The current
physmap.c code just assumes that the platfom_device_register will always
succeed.

Catch this failure during the physmap_init and propogate the error.

Signed-off-by: H Hartley Sweeten <[email protected]>

---

diff --git a/drivers/mtd/maps/physmap.c b/drivers/mtd/maps/physmap.c
index d9603f7..426461a 100644
--- a/drivers/mtd/maps/physmap.c
+++ b/drivers/mtd/maps/physmap.c
@@ -264,8 +264,11 @@ static int __init physmap_init(void)

err = platform_driver_register(&physmap_flash_driver);
#ifdef CONFIG_MTD_PHYSMAP_COMPAT
- if (err == 0)
- platform_device_register(&physmap_flash);
+ if (err == 0) {
+ err = platform_device_register(&physmap_flash);
+ if (err)
+ platform_driver_unregister(&physmap_flash_driver);
+ }
#endif

return err;

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/