sd_mod load is delayed.

sd_mod load is delayed.

[Hai Zaar]

Hi!

I'm using 2.6.15 + udev 081 + udev rules from here:
http://ftp.jg555.com/udev/udev-cross-lfs.tar.bz2 Relevant modprobe rules are:
# hotplug
ENV{MODALIAS}="?*",    RUN+="/sbin/modprobe $env{MODALIAS}"

# scsi
SUBSYSTEM="scsi_device",   ACTION="add", SYSFS{device/type}="1",
SYSFS{device/vendor}="On[sS]tream", RUN+="/sbin/modprobe osst"
SUBSYSTEM="scsi_device",   ACTION="add", SYSFS{device/type}="1",
RUN+="/sbin/modprobe st"
SUBSYSTEM="scsi_device",   ACTION="add", SYSFS{device/type}="[45]",
RUN+="/sbin/modprobe sr_mod"
SUBSYSTEM="scsi_device",   ACTION="add", RUN+="/sbin/modprobe sg"

Those rules do not handle sd_mod loading, so I've added the following
line from SUSE rules:
SUBSYSTEM="scsi_device",   ACTION="add",
SYSFS{device/type}="0|7|14", RUN+="/sbin/modprobe sd_mod"

I have two storage controllers in my machine:
1. Intel SATA controller, handled by ata_piix driver.
2. LSI logic SCSI controller handled by mptlinux driver.

The situation:
During initramfs stage, if I trigger event only for SATA controller,
then after just 1 second lib_ata and  ata_piix modules are loaded
together with sd_mod and friends, and /proc/partitions is populated.
So just after 1-2 seconds I'm able boot from SATA.

When LSI logic event is triggered - mptlinux module is loaded and
spends about half a minute to scan the bus.

The problems with, that when I trigger events both for SATA and LSI
logic (like trigger_all_events function does), sd_mod is not get
loaded until _both_ SATA and LSI finish to initialize.
Why sd_mod is not get loaded just right after ata_piix has finished?

--
Zaar


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: sd_mod load is delayed.

[Andrey Borzenkov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 29 January 2006 12:29, Hai Zaar wrote:
> Hi!
>
> I'm using 2.6.15 + udev 081 + udev rules from here:
> http://ftp.jg555.com/udev/udev-cross-lfs.tar.bz2 Relevant modprobe rules
> are: # hotplug
> ENV{MODALIAS}="?*",    RUN+="/sbin/modprobe $env{MODALIAS}"
>
> # scsi
> SUBSYSTEM="scsi_device",   ACTION="add", SYSFS{device/type}="1",
> SYSFS{device/vendor}="On[sS]tream", RUN+="/sbin/modprobe osst"
> SUBSYSTEM="scsi_device",   ACTION="add", SYSFS{device/type}="1",
> RUN+="/sbin/modprobe st"
> SUBSYSTEM="scsi_device",   ACTION="add", SYSFS{device/type}="[45]",
> RUN+="/sbin/modprobe sr_mod"
> SUBSYSTEM="scsi_device",   ACTION="add", RUN+="/sbin/modprobe sg"
>
> Those rules do not handle sd_mod loading, so I've added the following
> line from SUSE rules:
> SUBSYSTEM="scsi_device",   ACTION="add",
> SYSFS{device/type}="0|7|14", RUN+="/sbin/modprobe sd_mod"
>
> I have two storage controllers in my machine:
> 1. Intel SATA controller, handled by ata_piix driver.
> 2. LSI logic SCSI controller handled by mptlinux driver.
>
> The situation:
> During initramfs stage, if I trigger event only for SATA controller,
> then after just 1 second lib_ata and  ata_piix modules are loaded
> together with sd_mod and friends, and /proc/partitions is populated.
> So just after 1-2 seconds I'm able boot from SATA.
>
> When LSI logic event is triggered - mptlinux module is loaded and
> spends about half a minute to scan the bus.
>
> The problems with, that when I trigger events both for SATA and LSI
> logic (like trigger_all_events function does), sd_mod is not get
> loaded until _both_ SATA and LSI finish to initialize.
> Why sd_mod is not get loaded just right after ata_piix has finished?
>


As far as I can tell, SCSI subsystem is using scan mutex; so only one HBA can 
do scanning at a time. Or so it appears. May be LSI is the frst one to kick 
in.

- -andrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD3JUDR6LMutpd94wRAskLAJ9zBL3CHW4ovt4vxApZp2cVsiuQRwCfdpRU
i+VgPRPUSNiTCOkoCyfrKoM=/SSI
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: sd_mod load is delayed.

[Andrey Borzenkov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 29 January 2006 13:12, Andrey Borzenkov wrote:
> As far as I can tell, SCSI subsystem is using scan mutex; so only one HBA
> can do scanning at a time. Or so it appears. May be LSI is the frst one to
> kick in.

Oops sorry ignore this, what I meant is per-host mutex.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD3JtaR6LMutpd94wRAjA4AJ9BSirniUNKm90bVBRYNAUzakhWcACgj7CT
rJRZpPxLyBDe3C+xWsyIO0U=vG4e
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: sd_mod load is delayed.

[Hai Zaar]

>
> On Sunday 29 January 2006 13:12, Andrey Borzenkov wrote:
> > As far as I can tell, SCSI subsystem is using scan mutex; so only one HBA
> > can do scanning at a time. Or so it appears. May be LSI is the frst one to
> > kick in.
>
> Oops sorry ignore this, what I meant is per-host mutex.
Anyway, it does not seem to  help.
Here are some numbers.
Working directory is /sys/bus/pci/devices.
  0000:00:1f.2 is SATA controller (ata_piix modalias)
  0000:02:09.0 is LSI logic controller (mptspi modalias)
Each command was run by /bin/bash, that was spawned right after 'udev
--deamon' in initramfs. After each command, the system was rebooted:

Emitting only SATA event
    echo add > 0000:00:1f.2/uevent; time while ! grep -q sda
/proc/partitions; do sleep 0.1; done
    real 0m0.209sec
    -----------------------------

Emitting both SATA and LSI events
    echo add > 0000:00:1f.2/uevent; echo add > 0000:02:09.0; time
while ! grep -q sda /proc/partitions; do sleep 0.1; done
    real 0m12.244s
    -----------------------------
As you may see there is significant increase. The same happens if we
use regular trigger_device_events function:
    trigger_device_events; time while ! grep -q sda /proc/partitions;
do sleep 0.1; done
    real 0m13.605sec
    -----------------------------
Now, if we run modprobe ourselves, it takes no time again!
    modprobe mptspi & modprobe ata_piix & time while ! grep -q sda
/proc/partitions; do sleep 0.1; done
    real 0m0.210s

Can anyone explain this?

--
Zaar


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: sd_mod load is delayed.

[Andrey Borzenkov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 29 January 2006 14:18, Hai Zaar wrote:
> > On Sunday 29 January 2006 13:12, Andrey Borzenkov wrote:
> > > As far as I can tell, SCSI subsystem is using scan mutex; so only one
> > > HBA can do scanning at a time. Or so it appears. May be LSI is the frst
> > > one to kick in.
> >
> > Oops sorry ignore this, what I meant is per-host mutex.
>
> Anyway, it does not seem to  help.
> Here are some numbers.
> Working directory is /sys/bus/pci/devices.
>   0000:00:1f.2 is SATA controller (ata_piix modalias)
>   0000:02:09.0 is LSI logic controller (mptspi modalias)
> Each command was run by /bin/bash, that was spawned right after 'udev
> --deamon' in initramfs. After each command, the system was rebooted:
>
> Emitting only SATA event
>     echo add > 0000:00:1f.2/uevent; time while ! grep -q sda
> /proc/partitions; do sleep 0.1; done
>     real 0m0.209sec
>     -----------------------------
>
> Emitting both SATA and LSI events
>     echo add > 0000:00:1f.2/uevent; echo add > 0000:02:09.0; time
> while ! grep -q sda /proc/partitions; do sleep 0.1; done
>     real 0m12.244s
>     -----------------------------
> As you may see there is significant increase. 

And for LSI only? 

- -andrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD3LQVR6LMutpd94wRAvotAJ4wYa8hrr5Aisy8R/RerdU2mQF2hwCfTyCR
qvFzPnr9aklyzEanaaQVz6Q=3pBi
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: sd_mod load is delayed.

[Hai Zaar]

On 1/29/06, Andrey Borzenkov <arvidjaar@mail.ru> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sunday 29 January 2006 14:18, Hai Zaar wrote:
> > > On Sunday 29 January 2006 13:12, Andrey Borzenkov wrote:
> > > > As far as I can tell, SCSI subsystem is using scan mutex; so only one
> > > > HBA can do scanning at a time. Or so it appears. May be LSI is the frst
> > > > one to kick in.
> > >
> > > Oops sorry ignore this, what I meant is per-host mutex.
> >
> > Anyway, it does not seem to  help.
> > Here are some numbers.
> > Working directory is /sys/bus/pci/devices.
> >   0000:00:1f.2 is SATA controller (ata_piix modalias)
> >   0000:02:09.0 is LSI logic controller (mptspi modalias)
> > Each command was run by /bin/bash, that was spawned right after 'udev
> > --deamon' in initramfs. After each command, the system was rebooted:
> >
> > Emitting only SATA event
> >     echo add > 0000:00:1f.2/uevent; time while ! grep -q sda
> > /proc/partitions; do sleep 0.1; done
> >     real 0m0.209sec
> >     -----------------------------
> >
> > Emitting both SATA and LSI events
> >     echo add > 0000:00:1f.2/uevent; echo add > 0000:02:09.0; time
> > while ! grep -q sda /proc/partitions; do sleep 0.1; done
> >     real 0m12.244s
> >     -----------------------------
> > As you may see there is significant increase.
>
> And for LSI only?
LSI currently (and usually) does not have any devices attached, so
mptspi and friends do not load sd_mod at all. If it helps, I can get
to SCSI disks, but only by tomorrow.

>
> - -andrey
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
>
> iD8DBQFD3LQVR6LMutpd94wRAvotAJ4wYa8hrr5Aisy8R/RerdU2mQF2hwCfTyCR
> qvFzPnr9aklyzEanaaQVz6Q> =3pBi
> -----END PGP SIGNATURE-----
>


--
Zaar


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: sd_mod load is delayed.

[Kay Sievers]

On Sun, Jan 29, 2006 at 11:29:28AM +0200, Hai Zaar wrote:
> I'm using 2.6.15 + udev 081 + udev rules from here:
> http://ftp.jg555.com/udev/udev-cross-lfs.tar.bz2 Relevant modprobe rules are:
> # hotplug
> ENV{MODALIAS}="?*",    RUN+="/sbin/modprobe $env{MODALIAS}"
> 
> # scsi
> SUBSYSTEM="scsi_device",   ACTION="add", SYSFS{device/type}="1",
> SYSFS{device/vendor}="On[sS]tream", RUN+="/sbin/modprobe osst"
> SUBSYSTEM="scsi_device",   ACTION="add", SYSFS{device/type}="1",
> RUN+="/sbin/modprobe st"
> SUBSYSTEM="scsi_device",   ACTION="add", SYSFS{device/type}="[45]",
> RUN+="/sbin/modprobe sr_mod"
> SUBSYSTEM="scsi_device",   ACTION="add", RUN+="/sbin/modprobe sg"
> 
> Those rules do not handle sd_mod loading, so I've added the following
> line from SUSE rules:
> SUBSYSTEM="scsi_device",   ACTION="add",
> SYSFS{device/type}="0|7|14", RUN+="/sbin/modprobe sd_mod"
> 
> I have two storage controllers in my machine:
> 1. Intel SATA controller, handled by ata_piix driver.
> 2. LSI logic SCSI controller handled by mptlinux driver.
> 
> The situation:
> During initramfs stage, if I trigger event only for SATA controller,
> then after just 1 second lib_ata and  ata_piix modules are loaded
> together with sd_mod and friends, and /proc/partitions is populated.
> So just after 1-2 seconds I'm able boot from SATA.


Try adding this:
  ACTION="add", SUBSYSTEM="scsi", WAIT_FOR_SYSFS="ioerr_cnt"

And better don't use the "device" link anywhere directly:
  SUBSYSTEM="scsi_device", ACTION="add", SYSFS{type}="0|7|14", RUN+="/sbin/modprobe sd_mod"

Kay


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: sd_mod load is delayed.

[Hai Zaar]

>
>
> Try adding this:
>   ACTION="add", SUBSYSTEM="scsi", WAIT_FOR_SYSFS="ioerr_cnt"
Added to 05-udev-early.rules:
ACTION="add",  DEVPATH="/devices/*", ENV{PHYSDEVBUS}="?*",
WAIT_FOR_SYSFS="bus"
ACTION="add",  SUBSYSTEM="net", WAIT_FOR_SYSFS="address"
# ???
ACTION="add", SUBSYSTEM="scsi", WAIT_FOR_SYSFS="ioerr_cnt"
SUBSYSTEM="drivers",           OPTIONS="ignore_device"
SUBSYSTEM="module",            OPTIONS="ignore_device"
Did not help :(
echo add > 0000:00:1f.2/uevent; echo add > 0000:02:09.0; time while !
grep -q sda /proc/partitions; do sleep 0.1; done
still 12 seconds (instead of < 1)

>
> And better don't use the "device" link anywhere directly:
>   SUBSYSTEM="scsi_device", ACTION="add", SYSFS{type}="0|7|14", RUN+="/sbin/modprobe sd_mod"
Applied. Did not do any help as well.

>
> Kay
>


--
Zaar


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: sd_mod load is delayed.

[Hai Zaar]

Well, I've got desperate trying to capture udev log during initramfs,
So I've patched it to log to /dev/udev.log. Patch is here if someone
is interested (very ugly):
http://www.math.technion.ac.il/~gmm/2.6.15_udev/udev-0.8.1-log-to-file-1.patch

Anyway, as I've mentioned, I run /bin/bash just after udevd --daemon. Then:
    echo add > 0000:00:1f.2/uevent; echo add > 0000:02:09.0/uevent
Udev log is here (first column is a number of seconds since epoch):
    http://www.math.technion.ac.il/~gmm/2.6.15_udev/udev.log.trigger
I can see that right away two modprobes are spawned (pid 389 is
mptspi, and pid 388 is ata_piix), but _both_ modprobes return after 12
seconds!!!

Ok, I reboot, and instead of triggering I run:
modprobe pci:v00008086d000024D1sv0000103Csd000012F2bc01sc01i8f &
modprobe pci:v00001000d00000030sv00001000sd00007110bc01sc00i00 &
And of course there are sda* entries in /proc/partitions just after 0.2 seconds.
udev log is here:
http://www.math.technion.ac.il/~gmm/2.6.15_udev/udev.log.modprobe

Does anyone known why does it behave this way?

On 1/29/06, Hai Zaar <haizaar@gmail.com> wrote:
> >
> >
> > Try adding this:
> >   ACTION="add", SUBSYSTEM="scsi", WAIT_FOR_SYSFS="ioerr_cnt"
> Added to 05-udev-early.rules:
> ACTION="add",  DEVPATH="/devices/*", ENV{PHYSDEVBUS}="?*",
> WAIT_FOR_SYSFS="bus"
> ACTION="add",  SUBSYSTEM="net", WAIT_FOR_SYSFS="address"
> # ???
> ACTION="add", SUBSYSTEM="scsi", WAIT_FOR_SYSFS="ioerr_cnt"
> SUBSYSTEM="drivers",           OPTIONS="ignore_device"
> SUBSYSTEM="module",            OPTIONS="ignore_device"
> Did not help :(
> echo add > 0000:00:1f.2/uevent; echo add > 0000:02:09.0; time while !
> grep -q sda /proc/partitions; do sleep 0.1; done
> still 12 seconds (instead of < 1)
>
> >
> > And better don't use the "device" link anywhere directly:
> >   SUBSYSTEM="scsi_device", ACTION="add", SYSFS{type}="0|7|14", RUN+="/sbin/modprobe sd_mod"
> Applied. Did not do any help as well.
>
> >
> > Kay
> >
>
>
> --
> Zaar
>


--
Zaar


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel