Bug 706989 - Boot stalls for ca. 5 min. (during "Starting udev:") with connected "U3 Cruzer Micro"-usb-stick.
Boot stalls for ca. 5 min. (during "Starting udev:") with connected "U3 Cruze...
Status: CLOSED DUPLICATE of bug 683265
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
15
Unspecified Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-23 13:24 EDT by Thomas Bruecker
Modified: 2011-05-24 09:53 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-05-24 09:53:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/proc/bus/usb/devices-4 (454 bytes, text/plain)
2011-05-23 13:24 EDT, Thomas Bruecker
no flags Details
/proc/bus/usb/devices-6 (470 bytes, text/plain)
2011-05-23 13:27 EDT, Thomas Bruecker
no flags Details
"/proc/bus/usb/devices-7" (451 bytes, text/plain)
2011-05-23 13:30 EDT, Thomas Bruecker
no flags Details
/proc/scsi/scsi-4 (319 bytes, text/plain)
2011-05-23 13:32 EDT, Thomas Bruecker
no flags Details
/proc/scsi/scsi-6 (160 bytes, text/plain)
2011-05-23 13:32 EDT, Thomas Bruecker
no flags Details
/proc/scsi/scsi-7 (319 bytes, text/plain)
2011-05-23 13:33 EDT, Thomas Bruecker
no flags Details
/proc/scsi/usb-storage/4 (180 bytes, text/plain)
2011-05-23 13:34 EDT, Thomas Bruecker
no flags Details
/proc/scsi/usb-storage/6 (196 bytes, text/plain)
2011-05-23 13:35 EDT, Thomas Bruecker
no flags Details
/proc/scsi/usb-storage/7 (177 bytes, text/plain)
2011-05-23 13:36 EDT, Thomas Bruecker
no flags Details

  None (edit)
Description Thomas Bruecker 2011-05-23 13:24:09 EDT
Created attachment 500467 [details]
/proc/bus/usb/devices-4

Description:
* Version: kernel-2.6.38.5-24.fc15.x86_64, kernel-2.6.38.6(x86_64)
                                                      (at least, see "Note 1").

* How reproducible:
  * Steps to Reproduce:
    * 1. the computer is turned off.
    * 2. the kernel is "kernel-2.6.38.6(x86_64)" ( see also "Note 1" and
                                                   "A Prelimary Remark [...]" )
    * 3. connect a e.g. (see "Note 2") "U3 Cruzer Micro"-usb-stick to the com-
         puter.
    * 4. start computer and boot-process for linux.

  * Actual Results:
    * the boot-process stalls for ca. 5 min (during "Starting udev:").
    * "Starting udev:" reports "FAILED".

    * further examination see "Complete Description".

  * Expected results:
    * after the diverse devices has been brought up, the boot-process should
      not stall.
    * "Starting udev:" reports "OK".

  * with a connected 'normal' cdrom-drive
                             (e.g. "HLDS Inc., Portable Super Multi DVD Drive")
    the boot-process does not stall and everything is fine.

  * with "kernel-2.6.35.13-91.fc14.x86_64" the boot-process does not stall if
    the mentioned-above usb-stick is connected.

* Preliminaries for further description (concerning notation etc.):
  * "SP", "$SP" etc. : variable-notation nearly according to bash.
  * # ... : a comment.
  * SP               := 'path to kernel source'.
  * FS_ROOT          := "/" # the root-path of the installed linux system.

  * CONDITION1       := only and only under "Steps to Reproduce",
                                                                 Steps 1,... 4.

  * CDROM.C          := "$SP/drivers/cdrom/cdrom.c"
                                          # file "cdrom.c" in "drivers/cdrom/".
  * GENHD.C          := "$SP/block/genhd.c"
  * KOBJECT_UEVENT.C := "$SP/lib/kobject_uevent.c"
  * RC.SYSINIT       := "$FS_ROOT/etc/rc.d/rc.sysinit"
  * SR.C             := "$SP/drivers/scsi/sr.c"
  * START_UDEV       := "$FS_ROOT/sbin/start_udev"

  * "$KOBJECT_UEVENT.C/kobject_uevent_env()" : function "kobject_uevent_env()"
    in file "$KOBJECT_UEVENT.C", etc.
  * "$KOBJECT_UEVENT.C/kobject_uevent_env()/line# 129" : line-number 129
    of file "$KOBJECT_UEVENT.C" in function "kobject_uevent_env()", etc.

* A Prelimary Remark (TO DESTROY YOUR DOUBTS!):
  I claim that the error will also occur under your
                                               "kernel-2.6.38.5-24.fc15.x86_64"
  because the files "$CDROM.C", "$GENHD.C", "$KOBJECT_UEVENT.C" and "$SR.C" are
  by pairs binary-identic for "kernel-2.6.38.6" and your
                           "kernel-2.6.38.5-24.fc15.x86_64", see also "Note 1".

* Complete Description:
  * the boot-process stalls at "$RC.SYSINIT/line# 139" : "/sbin/start_udev"
      at "$START_UDEV/line# 66" : "/sbin/udevadm settle".

  * further investigation (under $CONDITION1):
    * "$FS_ROOT/bin/ps" shows a lot of "udev"-processes.
    * executing "$FS_ROOT/sbin/udevadm monitor --kernel" produces the following
      output:
      "
        [...]
        KERNEL[1306001830.040626] change   /devices/pci0000:00/0000:00:1d.7/usb3/3-1/3-1:1.0/host4/target4:0:0/4:0:0:1/block/sr0 (block)
        KERNEL[1306001830.099675] change   /devices/pci0000:00/0000:00:1d.7/usb3/3-1/3-1:1.0/host4/target4:0:0/4:0:0:1/block/sr0 (block)
        KERNEL[1306001830.124843] change   /devices/pci0000:00/0000:00:1d.7/usb3/3-1/3-1:1.0/host4/target4:0:0/4:0:0:1/block/sr0 (block)
        KERNEL[1306001830.145162] change   /devices/pci0000:00/0000:00:1d.7/usb3/3-1/3-1:1.0/host4/target4:0:0/4:0:0:1/block/sr0 (block)
        KERNEL[1306001830.184409] change   /devices/pci0000:00/0000:00:1d.7/usb3/3-1/3-1:1.0/host4/target4:0:0/4:0:0:1/block/sr0 (block)
        KERNEL[1306001830.208849] change   /devices/pci0000:00/0000:00:1d.7/usb3/3-1/3-1:1.0/host4/target4:0:0/4:0:0:1/block/sr0 (block)
        KERNEL[1306001830.228932] change   /devices/pci0000:00/0000:00:1d.7/usb3/3-1/3-1:1.0/host4/target4:0:0/4:0:0:1/block/sr0 (block)
        KERNEL[1306001830.262076] change   /devices/pci0000:00/0000:00:1d.7/usb3/3-1/3-1:1.0/host4/target4:0:0/4:0:0:1/block/sr0 (block)
        KERNEL[1306001830.287169] change   /devices/pci0000:00/0000:00:1d.7/usb3/3-1/3-1:1.0/host4/target4:0:0/4:0:0:1/block/sr0 (block)
        KERNEL[1306001830.307056] change   /devices/pci0000:00/0000:00:1d.7/usb3/3-1/3-1:1.0/host4/target4:0:0/4:0:0:1/block/sr0 (block)
        KERNEL[1306001830.338226] change   /devices/pci0000:00/0000:00:1d.7/usb3/3-1/3-1:1.0/host4/target4:0:0/4:0:0:1/block/sr0 (block)
        KERNEL[1306001830.358716] change   /devices/pci0000:00/0000:00:1d.7/usb3/3-1/3-1:1.0/host4/target4:0:0/4:0:0:1/block/sr0 (block)
        KERNEL[1306001830.375847] change   /devices/pci0000:00/0000:00:1d.7/usb3/3-1/3-1:1.0/host4/target4:0:0/4:0:0:1/block/sr0 (block)
        KERNEL[1306001830.411190] change   /devices/pci0000:00/0000:00:1d.7/usb3/3-1/3-1:1.0/host4/target4:0:0/4:0:0:1/block/sr0 (block)
        [... and so on, endlessly.]
     "
    * mo more messages are displayed, when the usb-stick is removed.
    * mo more messages are displayed, if only a 'normal' cdrom-device is con-
      nected.
    * the messages continue, when the stick is connected again
    * remark: the "U3 Cruzer Micro"-usb-stick
                            (see also "Note 2", attachment "/proc/scsi/scsi-4")
      consists (after buying, applying no changes) of 2 internal devices:
      a cdrom and a scsi-disk.
    * the uevents arrive through the following path to "udevadm"
                                                               (the userspace):
      * "$KOBJECT_UEVENT.C/kobject_uevent_env()"
                                              at "$KOBJECT_UEVENT.C/line# 129",
        is called by:
          "$GENHD.C/disk_events_workfn()/line# 1596, 1597":
          "if (nr_events)
             kobject_uevent_env(&disk_to_dev(disk)->kobj, KOBJ_CHANGE, envp);",

      * the uevent here comes from "$GENHD.C/disk_events_workfn()/line# 1576":
                          "events = disk->fops->check_events(disk, clearing);",

      * this line calls "$SR.C/sr_block_check_events()" at "$SR.C/line# 539",

      * the uevent here comes from "$SR.C/sr_block_check_events()/line# 543":
                              "return cdrom_check_events(&cd->cdi, clearing);",

      * this line calls "$CDROM.C/cdrom_check_events()
                                                      at "$CDROM.C/line# 1423",

      * the uevent here comes from "$CDROM.C/cdrom_check_events()/line# 1428":
                                          "cdrom_update_events(cdi, clearing)",

      * this line calls "$CDROM.C/cdrom_update_events()"
                                                      at "$CDROM.C/line# 1413",

      * the uevent here comes from "$CDROM.C/cdrom_update_events()/line# 1418":
               "events = cdi->ops->check_events(cdi, clearing, CDSL_CURRENT);",

      * this line calls "$SR.C/sr_check_events()" at "$SR.C/line# 210",

      * the uevent here comes from "$SR.C/sr_check_events()/line# 223":
                                         "events = sr_get_events(cd->device);",

      * this line calls "$SR.C/sr_get_events()" at "$SR.C/line# 169",

      * the uevent here comes from "$SR.C/sr_get_events()/line# 198, 199":
        "else if (med->media_event_code == 2)
           return DISK_EVENT_MEDIA_CHANGE;"

      * finally, commenting out the above to lines stops delivering the events,
        when the usb-stick is connected:
        "/* else if (med->media_event_code == 2)
           return DISK_EVENT_MEDIA_CHANGE; */"

  * (i am not an expert) having a look at the "$SP/drivers/usb/storage/*"-
    souce-code (for module "usb_storage") lets me guess (especially because no
    case-distinction for scsi-command-constants
                                     [like e.g. "GET_EVENT_STATUS_NOTIFICATION]
    is done there), and because in the attachment "/proc/scsi/scsi-4" the
    usb-stick appears as 2 scsi-devices, that the scsi-commands are handled by
    the usb-stick itself.

  * actually the "cd" in the usb-stick can not be changed, so the usb-stick
    should not respond with "media-changed" to the scsi-command 
    "GET_EVENT_STATUS_NOTIFICATION" at "$SR.C/sr_get_events()/line# 172,ff":
                       "u8 cmd[] = { GET_EVENT_STATUS_NOTIFICATION, // [...] ".

  * maybe such sticks should be handled especially in the module "usb_storage",
    suppressing the result "media-changed" (too complicate for me).

* Note 1:
  * a comparison between the kernels "kernel-2.6.35.13-91.fc14.x86_64" and 
    "kernel-2.6.38.6" shows (me), that the architecture of uevent-propagation
    from (e.g.) cdroms to userspace has much changed from the kernel with the
    lower version# to the kernel with the higher version#; especially in
                                    "kernel-2.6.35.13-91.fc14.x86_64"(x86_64)",
    the media-change-status-check of a cdrom is not performed by something like
    the scsi-command "GET_EVENT_STATUS_NOTIFICATION".

  * obviously, there must exist a kernel, where the above architecture-change
    has be done the first time. (KERNEL_AC := 'this kernel').

  * let "$KERNEL_AC" have the version# "V", so I assume that all kernels, with
    version higher than "$V" will produce the same error under "$CONDITION1".

  * so "kernel-2.6.38.6" is not the only kernel wich produces the error.

* Note 2:
  * (at least) the following usb-sticks produce the error:
    * "Sandisk, U3 Cruzer Micro": see Attachments "/proc/bus/usb/devices-4",
                            "/proc/scsi/scsi-4" and "/proc/scsi/usb-storage/4".
    * "Sandisk, Ultra Backup": see Attachments "/proc/bus/usb/devices-7",
                            "/proc/scsi/scsi-7" and "/proc/scsi/usb-storage/7".

* Data for 'normal' cdrom-device: "HLDS Inc., Portable Super Multi DVD Drive":
  see Attachments "/proc/bus/usb/devices-6", "/proc/scsi/scsi-6" and
                                                    "/proc/scsi/usb-storage/6".

* the attachments
  * /proc/bus/usb/devices-4", "/proc/bus/usb/devices-6" and
    "/proc/bus/usb/devices-7" are taken from "$FS_ROOT/proc/bus/usb/devices",
  * "/proc/scsi/scsi-4", "/proc/scsi/scsi-6" and "/proc/scsi/scsi-7" are taken
    from "$FS_ROOT/proc/scsi/scsi",
  * "/proc/scsi/usb-storage/4", "/proc/scsi/usb-storage/6" and
    "/proc/scsi/usb-storage/7" are actually "$FS_ROOT/proc/scsi/usb-storage/4",
    "$FS_ROOT/proc/scsi/usb-storage/6", and "$FS_ROOT/proc/scsi/usb-storage/7".

* I do not send to you the debug-printouts and the debug-changes i have done
  to some files mentioned above, to get the debug printouts, but if you want me
  to prove, what i have claimed in "Complete Description", of course i can send
  them to you.
Comment 1 Thomas Bruecker 2011-05-23 13:27:23 EDT
Created attachment 500468 [details]
/proc/bus/usb/devices-6
Comment 2 Thomas Bruecker 2011-05-23 13:30:51 EDT
Created attachment 500469 [details]
"/proc/bus/usb/devices-7"
Comment 3 Thomas Bruecker 2011-05-23 13:32:07 EDT
Created attachment 500470 [details]
/proc/scsi/scsi-4
Comment 4 Thomas Bruecker 2011-05-23 13:32:48 EDT
Created attachment 500471 [details]
/proc/scsi/scsi-6
Comment 5 Thomas Bruecker 2011-05-23 13:33:33 EDT
Created attachment 500472 [details]
/proc/scsi/scsi-7
Comment 6 Thomas Bruecker 2011-05-23 13:34:42 EDT
Created attachment 500473 [details]
/proc/scsi/usb-storage/4
Comment 7 Thomas Bruecker 2011-05-23 13:35:41 EDT
Created attachment 500474 [details]
/proc/scsi/usb-storage/6
Comment 8 Thomas Bruecker 2011-05-23 13:36:54 EDT
Created attachment 500475 [details]
/proc/scsi/usb-storage/7
Comment 9 Thomas Bruecker 2011-05-23 14:10:10 EDT
Actually, i must admit (but i think without significance) i have done the
test in Fedora 14.
Comment 10 Thomas Bruecker 2011-05-23 15:32:48 EDT
* the error happens (as expected) too with your
                                             "kernel-2.6.38.6-27.fc15.x86_64".
  * here i have only tested 'Boot stalls ...' and 'executing
       "$FS_ROOT/sbin/udevadm monitor --kernel" produces the following output:
    "
      [...]
      KERNEL[ [...] ] change  
/devices/pci0000:00/0000:00:1d.7/usb3/3-1/3-1:1.0/host4/target4:0:0/4:0:0:1/block/sr0
(block)
      [...]
    " '
Comment 11 Chuck Ebbert 2011-05-24 09:53:06 EDT

*** This bug has been marked as a duplicate of bug 683265 ***

Note You need to log in before you can comment on or make changes to this bug.