Receiving two REMOVE actions for the same USB drive

[Mason]

Mason wrote:

> Hello everyone,
> 
> I'm using a vendor-supplied software stack which includes a
> "customized" Linux kernel (2.6.28) along with busybox v1.20.2
> 
> I'm seeing something strange from mdev when I unplug my USB
> mass storage device: the REMOVE action is notified twice
> with two different DEVPATH.
> 
> # cat /etc/mdev.conf
> $SUBSYSTEM=block 0:0 660 */application/usb_event.sh
> $SUBSYSTEM=net   0:0 660 */application/usb_event.sh
> 
> # cat /application/usb_event.sh
> printenv >> /tmp/stdout
> echo "+++" >> /tmp/stdout
> 
> # cat superfloppy.insert
> ACTION=add
> NPARTS=0
> HOME=/
> SEQNUM=302
> MAJOR=8
> MDEV=sda
> DEVPATH=/devices/platform/OEM-ehci-3.2/usb3/3-1/3-1:1.0/host1/target1:0:0/1:0:0:0/block/sda
> SUBSYSTEM=block
> PATH=/sbin:/bin:/usr/sbin:/usr/bin
> MINOR=0
> PWD=/dev
> DEVTYPE=disk
> +++
> 
> # cat superfloppy.remove
> ACTION=remove
> NPARTS=0
> HOME=/
> SEQNUM=310
> MAJOR=8
> MDEV=sda
> DEVPATH=/devices/platform/OEM-ehci-3.2/usb3/3-1/3-1:1.0/host1/target1:0:0/1:0:0:0/block/sda
> SUBSYSTEM=block
> PATH=/sbin:/bin:/usr/sbin:/usr/bin
> MINOR=0
> PWD=/dev
> DEVTYPE=disk
> +++
> ACTION=remove
> NPARTS=0
> HOME=/
> SEQNUM=311
> MAJOR=8
> MDEV=sda
> DEVPATH=/sda
> SUBSYSTEM=block
> PATH=/sbin:/bin:/usr/sbin:/usr/bin
> MINOR=0
> PWD=/dev
> DEVTYPE=disk
> +++
> 
> As you can see, the only difference between the two "remove" actions
> is the DEVPATH (and the SEQNUM of course).
> 
> DEVPATH=/devices/platform/OEM-ehci-3.2/usb3/3-1/3-1:1.0/host1/target1:0:0/1:0:0:0/block/sda
> DEVPATH=/sda
> 
> This double notification is annoying because I must filter it.
> I suppose this is not coming from mdev, but from the kernel?
> 
> Any idea why the kernel would notify twice?
> 
> Any idea on how to fix this problem?
> 
> Are there any tools I can use to better diagnose the problem?

Hello everyone,

Could someone with a similar kernel test insert/delete of a USB
mass-storage device, and tell me if you are notified twice for
the removal?

I think this weird behavior may have been introduced by the OEM's
patches, but I have no easy way of testing.

-- 
Regards.