Messages in this thread | | | Date | Wed, 8 Dec 2004 21:39:20 -0000 (WET) | Subject | Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6 | From | "Rui Nuno Capela" <> |
| |
Steven Rostedt wrote: >> Steven Rostedt wrote: >> > >> > I found a race condition in slab.c, but I'm still trying to figure >> > out exactly how it's playing out. This has to do with dynamic >> > loading and unloading of caches. I have a small test case that >> > simulates the problem at >> > http://home.stny.rr.com/rostedt/tests/sillycaches.tgz >> > >> > This was done on: >> > >> > # uname -r >> > 2.6.10-rc2-mm3-V0.7.32-9 >> >
> > Rui, > > Try adding the following in slab.c > > --- slab.c 2004-12-08 09:27:10.000000000 -0500 > +++ slab.c.new 2004-12-08 13:58:40.000000000 -0500 > @@ -1533,6 +1533,12 @@ > #ifndef CONFIG_PREEMPT_RT > smp_call_function_all_cpus(do_drain, cachep); > #endif > + { > + struct array_cache *ac; > + ac = ac_data(cachep, smp_processor_id()); > + free_block(cachep, &ac_entry(ac)[0], ac->avail); > + ac->avail = 0; > + } > check_irq_on(); > spin_lock_irq(&cachep->spinlock); > if (cachep->lists.shared) > > > and see if this fixes your usb problems. I would say that this is not a > proper fix and especially for a SMP system. But if it fixes your problem > then you know this is the solution. >
Almost there, perhaps not...
It doesn't solve the problem completely, if not at all. What was kind of a deterministic failure now seems probabilistic: the fault still occur on unplugging the usb-storage stick, but not everytime as before.
Did try several times, reboot included, and now it fails after unplugging a second or a third time. Never needed to replug/unplug more than 3 times for it to show up, however.
Here is one sample, taken on the patched RT-V0.7.32-9:
usb 4-5: USB disconnect, address 7 slab error in kmem_cache_destroy(): cache `scsi_cmd_cache': Can't free all objects [<c010361f>] dump_stack+0x23/0x25 (20) [<c014669f>] kmem_cache_destroy+0x103/0x1aa (28) [<c026e61a>] scsi_destroy_command_freelist+0x97/0xa8 (28) [<c026f451>] scsi_host_dev_release+0x37/0xe1 (104) [<c023c569>] device_release+0x7a/0x7c (32) [<c01efc50>] kobject_cleanup+0x87/0x89 (28) [<c01f06ab>] kref_put+0x52/0xef (40) [<c01efc8c>] kobject_put+0x25/0x27 (16) [<f8cf1843>] usb_stor_release_resources+0x66/0xca [usb_storage] (16) [<f8cf1d93>] storage_disconnect+0x8e/0x9b [usb_storage] (16) [<f89ca117>] usb_unbind_interface+0x84/0x86 [usbcore] (28) [<c023d7d5>] device_release_driver+0x75/0x77 (28) [<c023d9d8>] bus_remove_device+0x53/0x82 (20) [<c023c9a1>] device_del+0x4b/0x9b (20) [<f89d142a>] usb_disable_device+0xf5/0x10a [usbcore] (28) [<f89cc61c>] usb_disconnect+0xc8/0x164 [usbcore] (40) [<f89cd77e>] hub_port_connect_change+0x2ef/0x426 [usbcore] (56) [<f89cda7b>] hub_events+0x1c6/0x39d [usbcore] (56) [<f89cdc89>] hub_thread+0x37/0x109 [usbcore] (96) [<c01009b1>] kernel_thread_helper+0x5/0xb (150118420)
Bye now. -- rncbc aka Rui Nuno Capela rncbc@rncbc.org
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |