Hi Bernd On Wed, 27 May 2015 22:11:38 +0200 =?UTF-8?B?QmVybmhhcmQgw5xiZWxhY2tlcg==?= <bernha...@vr-web.de> wrote: > Hello Marco, hello Michael, > sorry for the delay. > This is just to add some points to the bug. > > > On Sat, 11 Apr 2015 16:04:50 +0200 m...@linux.it (Marco d'Itri) wrote: > > Unless something is creating an events loop then this is an hardware > > issue or a kernel bug. > > Considering that this only happens with a specific USB stick I will > > assume that it is broken. > > To me it looks like the creators of this stick intentionally made a > waiting time of 5 seconds between being recognized as USB stick and > actually "inserting" the "media" into it, like a card reader. > In this 5 seconds the kernel always tries to open the "media" and triggers > new block-change events (possibly by being triggered by blkid runs triggered > by udev triggered by the first block-change event). > This accumulates to ~700 messages in this 5 seconds, which now taking nearly a > minute for udev to process. > If such a behaviour is allowed I cannot say. > > > With attached printk-KOBJ_CHANGE.diff I isolated the two origins of > these block-change events on the kernel side: > Mai 27 21:02:12.125582 rechner kernel: disk_check_events: > kobject_uevent_env KOBJ_CHANGE nr_events=1 envp[0]=DISK_MEDIA_CHANGE=1 size=0 > (405 times) > Mai 27 21:02:12.130620 rechner kernel: invalidate_partitions: > kobject_uevent KOBJ_CHANGE (0/0) > (323 times) > > > These are the origins of the function calls, as far as I could follow them: > blkdev_get > __blkdev_get (block_dev.c) > invalidate_partitions (partition-generic.c) > > check_disk_change (block_dev.c) > disk_clear_events (genhd.c) > disk_check_events (genhd.c) > > add_disk (genhd.c) > disk_alloc_events via INIT_DELAYED_WORK (genhd.c) > disk_events_workfn (genhd.c) > disk_check_events (genhd.c) > > > I tried to find a way to avoid some of these events and possibly > have found something for the invalidate_partitions path at least: > Does it make sense to send the block-change event in invalidate_partitions > when the disk had a size of 0 before and after checking its size? > (Or call invalidate_partitions in this case at all?) > > > The second point is following question: > Does it make sense to insert an identically block-change event for this > device > when we know that there are already some in the queue? > (See attached drop-block-change-events-already-in-queue.patch)
just wanted to ask, if you still run into this issue with a newer kernel (from testing). If so, I think it would probably best to re-assign this. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
