* scsi_wait_scan not working (2.6.30.5)
@ 2009-08-25 19:24 Arkadiusz Miskiewicz
2009-08-25 19:28 ` James Bottomley
0 siblings, 1 reply; 14+ messages in thread
From: Arkadiusz Miskiewicz @ 2009-08-25 19:24 UTC (permalink / raw)
To: linux-scsi
Hi,
What could be the reason for scsi_wait_scan not waiting untill all disks are
found?
I'm testing 2.6.30.5 on hardware with LSI Logic / Symbios Logic MegaRAID 530
SCSI 320-0X RAID controller and modprobe scsi_wait_scan finishes earlier than
disks are found.
My initrd (romfs) does:
insmod /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/scsi_mod.ko
insmod /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/megaraid/megaraid_mm.ko
insmod /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/megaraid/megaraid_mbox.ko
insmod /lib/modules/2.6.30.5-0.3/kernel/lib/crc-t10dif.ko
insmod /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/sd_mod.ko
insmod /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/scsi_wait_scan.ko
insmod /lib/modules/2.6.30.5-0.3/kernel/fs/exportfs/exportfs.ko
insmod /lib/modules/2.6.30.5-0.3/kernel/fs/xfs/xfs.ko
if [ "${ROOT##/dev/}" != "${ROOT}" ]; then
rootnr="$(busybox awk -v rootnode="${ROOT##/dev/}" '$4 == rootnode { print 256
* $1 + $2 }' /proc/partitions)"
if [ -n "$rootnr" ]; then
echo "$rootnr" > /proc/sys/kernel/real-root-dev
fi
Now if I add sleep few seconds or /bin/sh at the end of this initrd, then boot
and then disks are detected properly and rootfs is mounted properly (after I
exit from sh in case when /bin/sh is used).
The question remains - why scsi_wait_scan doesn't wait?
[root@rhea ~]# zgrep SCSI /proc/config.gz
CONFIG_CISS_SCSI_TAPE=y
# SCSI device support
CONFIG_SCSI=m
CONFIG_SCSI_DMA=y
CONFIG_SCSI_TGT=m
CONFIG_SCSI_NETLINK=y
CONFIG_SCSI_PROC_FS=y
# SCSI support type (disk, tape, CD-ROM)
CONFIG_SCSI_ENCLOSURE=m
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
CONFIG_SCSI_MULTI_LUN=y
# CONFIG_SCSI_CONSTANTS is not set
CONFIG_SCSI_LOGGING=y
CONFIG_SCSI_SCAN_ASYNC=y
CONFIG_SCSI_WAIT_SCAN=m
# SCSI Transports
CONFIG_SCSI_SPI_ATTRS=m
CONFIG_SCSI_FC_ATTRS=m
CONFIG_SCSI_FC_TGT_ATTRS=y
CONFIG_SCSI_ISCSI_ATTRS=m
CONFIG_SCSI_SAS_ATTRS=m
CONFIG_SCSI_SAS_LIBSAS=m
CONFIG_SCSI_SAS_ATA=y
CONFIG_SCSI_SAS_HOST_SMP=y
# CONFIG_SCSI_SAS_LIBSAS_DEBUG is not set
CONFIG_SCSI_SRP_ATTRS=m
CONFIG_SCSI_SRP_TGT_ATTRS=y
CONFIG_SCSI_LOWLEVEL=y
CONFIG_ISCSI_TCP=m
CONFIG_SCSI_CXGB3_ISCSI=m
CONFIG_SCSI_3W_9XXX=m
CONFIG_SCSI_ACARD=m
CONFIG_SCSI_AACRAID=m
CONFIG_SCSI_AIC7XXX=m
CONFIG_SCSI_AIC7XXX_OLD=m
CONFIG_SCSI_AIC79XX=m
CONFIG_SCSI_AIC94XX=m
CONFIG_SCSI_DPT_I2O=m
CONFIG_SCSI_ADVANSYS=m
CONFIG_SCSI_ARCMSR=m
CONFIG_SCSI_ARCMSR_AER=y
CONFIG_SCSI_MPT2SAS=m
CONFIG_SCSI_MPT2SAS_MAX_SGE=128
CONFIG_SCSI_MPT2SAS_LOGGING=y
CONFIG_SCSI_HPTIOP=m
CONFIG_SCSI_BUSLOGIC=m
CONFIG_SCSI_DMX3191D=m
CONFIG_SCSI_EATA=m
CONFIG_SCSI_EATA_TAGGED_QUEUE=y
CONFIG_SCSI_EATA_LINKED_COMMANDS=y
CONFIG_SCSI_EATA_MAX_TAGS=62
CONFIG_SCSI_FUTURE_DOMAIN=m
CONFIG_SCSI_GDTH=m
CONFIG_SCSI_IPS=m
CONFIG_SCSI_INITIO=m
CONFIG_SCSI_INIA100=m
CONFIG_SCSI_PPA=m
CONFIG_SCSI_IMM=m
# CONFIG_SCSI_IZIP_EPP16 is not set
# CONFIG_SCSI_IZIP_SLOW_CTR is not set
CONFIG_SCSI_MVSAS=m
CONFIG_SCSI_STEX=m
CONFIG_SCSI_SYM53C8XX_2=m
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=256
CONFIG_SCSI_SYM53C8XX_MMIO=y
CONFIG_SCSI_IPR=m
CONFIG_SCSI_IPR_TRACE=y
CONFIG_SCSI_IPR_DUMP=y
CONFIG_SCSI_QLOGIC_1280=m
CONFIG_SCSI_QLA_FC=m
CONFIG_SCSI_QLA_ISCSI=m
CONFIG_SCSI_LPFC=m
# CONFIG_SCSI_LPFC_DEBUG_FS is not set
CONFIG_SCSI_DC395x=m
CONFIG_SCSI_DC390T=m
CONFIG_SCSI_DEBUG=m
CONFIG_SCSI_SRP=m
CONFIG_SCSI_LOWLEVEL_PCMCIA=y
CONFIG_SCSI_DH=m
CONFIG_SCSI_DH_RDAC=m
CONFIG_SCSI_DH_HP_SW=m
CONFIG_SCSI_DH_EMC=m
CONFIG_SCSI_DH_ALUA=m
CONFIG_SCSI_OSD_INITIATOR=m
CONFIG_SCSI_OSD_ULD=m
CONFIG_SCSI_OSD_DPRINT_SENSE=1
# CONFIG_SCSI_OSD_DEBUG is not set
CONFIG_I2O_SCSI=m
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
CONFIG_ISCSI_IBFT_FIND=y
CONFIG_ISCSI_IBFT=m
--
Arkadiusz Miśkiewicz PLD/Linux Team
arekm / maven.pl http://ftp.pld-linux.org/
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: scsi_wait_scan not working (2.6.30.5) 2009-08-25 19:24 scsi_wait_scan not working (2.6.30.5) Arkadiusz Miskiewicz @ 2009-08-25 19:28 ` James Bottomley 2009-08-25 19:44 ` Arkadiusz Miskiewicz 2009-08-26 14:34 ` Chris Webb 0 siblings, 2 replies; 14+ messages in thread From: James Bottomley @ 2009-08-25 19:28 UTC (permalink / raw) To: Arkadiusz Miskiewicz; +Cc: linux-scsi, Arjan van de Ven On Tue, 2009-08-25 at 21:24 +0200, Arkadiusz Miskiewicz wrote: > What could be the reason for scsi_wait_scan not waiting untill all disks are > found? > > I'm testing 2.6.30.5 on hardware with LSI Logic / Symbios Logic MegaRAID 530 > SCSI 320-0X RAID controller and modprobe scsi_wait_scan finishes earlier than > disks are found. > > My initrd (romfs) does: > insmod /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/scsi_mod.ko > insmod /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/megaraid/megaraid_mm.ko > insmod /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/megaraid/megaraid_mbox.ko > insmod /lib/modules/2.6.30.5-0.3/kernel/lib/crc-t10dif.ko > insmod /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/sd_mod.ko > insmod /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/scsi_wait_scan.ko > insmod /lib/modules/2.6.30.5-0.3/kernel/fs/exportfs/exportfs.ko > insmod /lib/modules/2.6.30.5-0.3/kernel/fs/xfs/xfs.ko > if [ "${ROOT##/dev/}" != "${ROOT}" ]; then > rootnr="$(busybox awk -v rootnode="${ROOT##/dev/}" '$4 == rootnode { print 256 > * $1 + $2 }' /proc/partitions)" > if [ -n "$rootnr" ]; then > echo "$rootnr" > /proc/sys/kernel/real-root-dev > fi > > > Now if I add sleep few seconds or /bin/sh at the end of this initrd, then boot > and then disks are detected properly and rootfs is mounted properly (after I > exit from sh in case when /bin/sh is used). > > The question remains - why scsi_wait_scan doesn't wait? It's caused by the sd async patches. What's happening is wait_scan is waiting until all the scans are complete, but now sd attachment may not be completed by the time that happens. So, although you have a scanned disk, you can't mount it without and attached sd driver. Hopefully when all initrds are configured to wait until root appears, this problem will go away. James ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: scsi_wait_scan not working (2.6.30.5) 2009-08-25 19:28 ` James Bottomley @ 2009-08-25 19:44 ` Arkadiusz Miskiewicz 2009-08-25 19:47 ` James Bottomley 2009-08-26 14:34 ` Chris Webb 1 sibling, 1 reply; 14+ messages in thread From: Arkadiusz Miskiewicz @ 2009-08-25 19:44 UTC (permalink / raw) To: James Bottomley; +Cc: linux-scsi, Arjan van de Ven On Tuesday 25 of August 2009, James Bottomley wrote: > On Tue, 2009-08-25 at 21:24 +0200, Arkadiusz Miskiewicz wrote: > > What could be the reason for scsi_wait_scan not waiting untill all disks > > are found? > > > > I'm testing 2.6.30.5 on hardware with LSI Logic / Symbios Logic MegaRAID > > 530 SCSI 320-0X RAID controller and modprobe scsi_wait_scan finishes > > earlier than disks are found. > > > > My initrd (romfs) does: > > insmod /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/scsi_mod.ko > > insmod > > /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/megaraid/megaraid_mm.ko > > insmod > > /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/megaraid/megaraid_mbox.ko > > insmod /lib/modules/2.6.30.5-0.3/kernel/lib/crc-t10dif.ko > > insmod /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/sd_mod.ko > > insmod /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/scsi_wait_scan.ko > > insmod /lib/modules/2.6.30.5-0.3/kernel/fs/exportfs/exportfs.ko > > insmod /lib/modules/2.6.30.5-0.3/kernel/fs/xfs/xfs.ko > > if [ "${ROOT##/dev/}" != "${ROOT}" ]; then > > rootnr="$(busybox awk -v rootnode="${ROOT##/dev/}" '$4 == rootnode { > > print 256 * $1 + $2 }' /proc/partitions)" > > if [ -n "$rootnr" ]; then > > echo "$rootnr" > /proc/sys/kernel/real-root-dev > > fi > > > > > > Now if I add sleep few seconds or /bin/sh at the end of this initrd, then > > boot and then disks are detected properly and rootfs is mounted properly > > (after I exit from sh in case when /bin/sh is used). > > > > The question remains - why scsi_wait_scan doesn't wait? > > It's caused by the sd async patches. What's happening is wait_scan is > waiting until all the scans are complete, but now sd attachment may not > be completed by the time that happens. So, although you have a scanned > disk, you can't mount it without and attached sd driver. > Hopefully when > all initrds are configured to wait until root appears, this problem will > go away. Uh, ugly. I'll disable SCSI_SCAN_ASYNC here then. Anyway what's the point of scsi_wait_scan module if initrd is still required to wait until root appears? (unless current behaviour is broken behaviour meant to be fixed?) Thanks! > James -- Arkadiusz Miśkiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: scsi_wait_scan not working (2.6.30.5) 2009-08-25 19:44 ` Arkadiusz Miskiewicz @ 2009-08-25 19:47 ` James Bottomley 2009-08-25 20:01 ` Arkadiusz Miskiewicz 0 siblings, 1 reply; 14+ messages in thread From: James Bottomley @ 2009-08-25 19:47 UTC (permalink / raw) To: Arkadiusz Miskiewicz; +Cc: linux-scsi, Arjan van de Ven On Tue, 2009-08-25 at 21:44 +0200, Arkadiusz Miskiewicz wrote: > On Tuesday 25 of August 2009, James Bottomley wrote: > > On Tue, 2009-08-25 at 21:24 +0200, Arkadiusz Miskiewicz wrote: > > > What could be the reason for scsi_wait_scan not waiting untill all disks > > > are found? > > > > > > I'm testing 2.6.30.5 on hardware with LSI Logic / Symbios Logic MegaRAID > > > 530 SCSI 320-0X RAID controller and modprobe scsi_wait_scan finishes > > > earlier than disks are found. > > > > > > My initrd (romfs) does: > > > insmod /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/scsi_mod.ko > > > insmod > > > /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/megaraid/megaraid_mm.ko > > > insmod > > > /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/megaraid/megaraid_mbox.ko > > > insmod /lib/modules/2.6.30.5-0.3/kernel/lib/crc-t10dif.ko > > > insmod /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/sd_mod.ko > > > insmod /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/scsi_wait_scan.ko > > > insmod /lib/modules/2.6.30.5-0.3/kernel/fs/exportfs/exportfs.ko > > > insmod /lib/modules/2.6.30.5-0.3/kernel/fs/xfs/xfs.ko > > > if [ "${ROOT##/dev/}" != "${ROOT}" ]; then > > > rootnr="$(busybox awk -v rootnode="${ROOT##/dev/}" '$4 == rootnode { > > > print 256 * $1 + $2 }' /proc/partitions)" > > > if [ -n "$rootnr" ]; then > > > echo "$rootnr" > /proc/sys/kernel/real-root-dev > > > fi > > > > > > > > > Now if I add sleep few seconds or /bin/sh at the end of this initrd, then > > > boot and then disks are detected properly and rootfs is mounted properly > > > (after I exit from sh in case when /bin/sh is used). > > > > > > The question remains - why scsi_wait_scan doesn't wait? > > > > It's caused by the sd async patches. What's happening is wait_scan is > > waiting until all the scans are complete, but now sd attachment may not > > be completed by the time that happens. So, although you have a scanned > > disk, you can't mount it without and attached sd driver. > > > Hopefully when > > all initrds are configured to wait until root appears, this problem will > > go away. > > Uh, ugly. I'll disable SCSI_SCAN_ASYNC here then. That won't actually help: the sd async scan is a separate mechanism not tied to that variable > Anyway what's the point of scsi_wait_scan module if initrd is still required > to wait until root appears? (unless current behaviour is broken behaviour > meant to be fixed?) It was supposed to be an interim measure until the ditributions got their act together for initrd booting by waiting for the root disk to appear. It's just been "interim" for a bit longer than expected. James ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: scsi_wait_scan not working (2.6.30.5) 2009-08-25 19:47 ` James Bottomley @ 2009-08-25 20:01 ` Arkadiusz Miskiewicz 2009-08-25 21:22 ` Arkadiusz Miskiewicz 0 siblings, 1 reply; 14+ messages in thread From: Arkadiusz Miskiewicz @ 2009-08-25 20:01 UTC (permalink / raw) To: James Bottomley; +Cc: linux-scsi, Arjan van de Ven On Tuesday 25 of August 2009, you wrote: > On Tue, 2009-08-25 at 21:44 +0200, Arkadiusz Miskiewicz wrote: > > On Tuesday 25 of August 2009, James Bottomley wrote: > > > On Tue, 2009-08-25 at 21:24 +0200, Arkadiusz Miskiewicz wrote: > > > > What could be the reason for scsi_wait_scan not waiting untill all > > > > disks are found? > > > > > > > > I'm testing 2.6.30.5 on hardware with LSI Logic / Symbios Logic > > > > MegaRAID 530 SCSI 320-0X RAID controller and modprobe scsi_wait_scan > > > > finishes earlier than disks are found. > > > > > > > > My initrd (romfs) does: > > > > insmod /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/scsi_mod.ko > > > > insmod > > > > /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/megaraid/megaraid_mm.ko > > > > insmod > > > > /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/megaraid/megaraid_mbox. > > > >ko insmod /lib/modules/2.6.30.5-0.3/kernel/lib/crc-t10dif.ko > > > > insmod /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/sd_mod.ko > > > > insmod > > > > /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/scsi_wait_scan.ko > > > > insmod /lib/modules/2.6.30.5-0.3/kernel/fs/exportfs/exportfs.ko > > > > insmod /lib/modules/2.6.30.5-0.3/kernel/fs/xfs/xfs.ko > > > > if [ "${ROOT##/dev/}" != "${ROOT}" ]; then > > > > rootnr="$(busybox awk -v rootnode="${ROOT##/dev/}" '$4 == rootnode { > > > > print 256 * $1 + $2 }' /proc/partitions)" > > > > if [ -n "$rootnr" ]; then > > > > echo "$rootnr" > /proc/sys/kernel/real-root-dev > > > > fi > > > > > > > > > > > > Now if I add sleep few seconds or /bin/sh at the end of this initrd, > > > > then boot and then disks are detected properly and rootfs is mounted > > > > properly (after I exit from sh in case when /bin/sh is used). > > > > > > > > The question remains - why scsi_wait_scan doesn't wait? > > > > > > It's caused by the sd async patches. What's happening is wait_scan is > > > waiting until all the scans are complete, but now sd attachment may not > > > be completed by the time that happens. So, although you have a scanned > > > disk, you can't mount it without and attached sd driver. > > > > > > Hopefully when > > > all initrds are configured to wait until root appears, this problem > > > will go away. > > > > Uh, ugly. I'll disable SCSI_SCAN_ASYNC here then. > > That won't actually help: the sd async scan is a separate mechanism not > tied to that variable I assume there is no configurable way to disable this? > > > Anyway what's the point of scsi_wait_scan module if initrd is still > > required to wait until root appears? (unless current behaviour is broken > > behaviour meant to be fixed?) > > It was supposed to be an interim measure until the ditributions got > their act together for initrd booting by waiting for the root disk to > appear. It's just been "interim" for a bit longer than expected. Isn't kernel better place for this? Handling that in userspace is very complicated for such setups like fs on top of software raid where raid is assembled by UUID of devices etc, etc. Userspace will need to handle all weird cases to figure out what devices are needed (eg. parse mdadm config) to be able to wait for thsese and then go into next step. Are major distros actually handling this well? > James -- Arkadiusz Miśkiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: scsi_wait_scan not working (2.6.30.5) 2009-08-25 20:01 ` Arkadiusz Miskiewicz @ 2009-08-25 21:22 ` Arkadiusz Miskiewicz 2009-08-25 23:15 ` Alan Stern 0 siblings, 1 reply; 14+ messages in thread From: Arkadiusz Miskiewicz @ 2009-08-25 21:22 UTC (permalink / raw) To: James Bottomley; +Cc: linux-scsi, Arjan van de Ven, Alan Stern On Tuesday 25 of August 2009, Arkadiusz Miskiewicz wrote: > On Tuesday 25 of August 2009, you wrote: > > On Tue, 2009-08-25 at 21:44 +0200, Arkadiusz Miskiewicz wrote: > > > On Tuesday 25 of August 2009, James Bottomley wrote: > > > > On Tue, 2009-08-25 at 21:24 +0200, Arkadiusz Miskiewicz wrote: > > > > > What could be the reason for scsi_wait_scan not waiting untill all > > > > > disks are found? > > > > > > > > > > I'm testing 2.6.30.5 on hardware with LSI Logic / Symbios Logic > > > > > MegaRAID 530 SCSI 320-0X RAID controller and modprobe > > > > > scsi_wait_scan finishes earlier than disks are found. > > > > > > > > > > My initrd (romfs) does: > > > > > insmod /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/scsi_mod.ko > > > > > insmod > > > > > /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/megaraid/megaraid_mm. > > > > >ko insmod > > > > > /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/megaraid/megaraid_mbo > > > > >x. ko insmod /lib/modules/2.6.30.5-0.3/kernel/lib/crc-t10dif.ko > > > > > insmod /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/sd_mod.ko > > > > > insmod > > > > > /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/scsi_wait_scan.ko > > > > > insmod /lib/modules/2.6.30.5-0.3/kernel/fs/exportfs/exportfs.ko > > > > > insmod /lib/modules/2.6.30.5-0.3/kernel/fs/xfs/xfs.ko > > > > > if [ "${ROOT##/dev/}" != "${ROOT}" ]; then > > > > > rootnr="$(busybox awk -v rootnode="${ROOT##/dev/}" '$4 == rootnode > > > > > { print 256 * $1 + $2 }' /proc/partitions)" > > > > > if [ -n "$rootnr" ]; then > > > > > echo "$rootnr" > /proc/sys/kernel/real-root-dev > > > > > fi > > > > > > > > > > > > > > > Now if I add sleep few seconds or /bin/sh at the end of this > > > > > initrd, then boot and then disks are detected properly and rootfs > > > > > is mounted properly (after I exit from sh in case when /bin/sh is > > > > > used). > > > > > > > > > > The question remains - why scsi_wait_scan doesn't wait? > > > > > > > > It's caused by the sd async patches. What's happening is wait_scan > > > > is waiting until all the scans are complete, but now sd attachment > > > > may not be completed by the time that happens. So, although you have > > > > a scanned disk, you can't mount it without and attached sd driver. > > > > > > > > Hopefully when > > > > all initrds are configured to wait until root appears, this problem > > > > will go away. > > > > > > Uh, ugly. I'll disable SCSI_SCAN_ASYNC here then. > > > > That won't actually help: the sd async scan is a separate mechanism not > > tied to that variable > > I assume there is no configurable way to disable this? I found this patch http://marc.info/?l=linux-scsi&m=124388639906873&w=2 but it doesn't work on 30.5 (it's still not waiting untill everything is discovered) -- Arkadiusz Miśkiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: scsi_wait_scan not working (2.6.30.5) 2009-08-25 21:22 ` Arkadiusz Miskiewicz @ 2009-08-25 23:15 ` Alan Stern 2009-08-29 23:27 ` Arkadiusz Miskiewicz 0 siblings, 1 reply; 14+ messages in thread From: Alan Stern @ 2009-08-25 23:15 UTC (permalink / raw) To: Arkadiusz Miskiewicz; +Cc: James Bottomley, linux-scsi, Arjan van de Ven On Tue, 25 Aug 2009, Arkadiusz Miskiewicz wrote: > On Tuesday 25 of August 2009, Arkadiusz Miskiewicz wrote: > > On Tuesday 25 of August 2009, you wrote: > > > On Tue, 2009-08-25 at 21:44 +0200, Arkadiusz Miskiewicz wrote: > > > > On Tuesday 25 of August 2009, James Bottomley wrote: > > > > > On Tue, 2009-08-25 at 21:24 +0200, Arkadiusz Miskiewicz wrote: > > > > > > What could be the reason for scsi_wait_scan not waiting untill all > > > > > > disks are found? > > > > > > > > > > > > I'm testing 2.6.30.5 on hardware with LSI Logic / Symbios Logic > > > > > > MegaRAID 530 SCSI 320-0X RAID controller and modprobe > > > > > > scsi_wait_scan finishes earlier than disks are found. > > > > > > > > > > > > My initrd (romfs) does: > > > > > > insmod /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/scsi_mod.ko > > > > > > insmod > > > > > > /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/megaraid/megaraid_mm. > > > > > >ko insmod > > > > > > /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/megaraid/megaraid_mbo > > > > > >x. ko insmod /lib/modules/2.6.30.5-0.3/kernel/lib/crc-t10dif.ko > > > > > > insmod /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/sd_mod.ko > > > > > > insmod > > > > > > /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/scsi_wait_scan.ko > > > > > > insmod /lib/modules/2.6.30.5-0.3/kernel/fs/exportfs/exportfs.ko > > > > > > insmod /lib/modules/2.6.30.5-0.3/kernel/fs/xfs/xfs.ko > > > > > > if [ "${ROOT##/dev/}" != "${ROOT}" ]; then > > > > > > rootnr="$(busybox awk -v rootnode="${ROOT##/dev/}" '$4 == rootnode > > > > > > { print 256 * $1 + $2 }' /proc/partitions)" > > > > > > if [ -n "$rootnr" ]; then > > > > > > echo "$rootnr" > /proc/sys/kernel/real-root-dev > > > > > > fi > > > > > > > > > > > > > > > > > > Now if I add sleep few seconds or /bin/sh at the end of this > > > > > > initrd, then boot and then disks are detected properly and rootfs > > > > > > is mounted properly (after I exit from sh in case when /bin/sh is > > > > > > used). > > > > > > > > > > > > The question remains - why scsi_wait_scan doesn't wait? > > > > > > > > > > It's caused by the sd async patches. What's happening is wait_scan > > > > > is waiting until all the scans are complete, but now sd attachment > > > > > may not be completed by the time that happens. So, although you have > > > > > a scanned disk, you can't mount it without and attached sd driver. > > > > > > > > > > Hopefully when > > > > > all initrds are configured to wait until root appears, this problem > > > > > will go away. > > > > > > > > Uh, ugly. I'll disable SCSI_SCAN_ASYNC here then. > > > > > > That won't actually help: the sd async scan is a separate mechanism not > > > tied to that variable > > > > I assume there is no configurable way to disable this? > > I found this patch > > http://marc.info/?l=linux-scsi&m=124388639906873&w=2 > > but it doesn't work on 30.5 (it's still not waiting untill everything is > discovered) Did you remember to rebuild your initrd after applying this patch and rebuilding the module? Can you provide the dmesg log showing what happens during bootup with the patch applied? Alan Stern ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: scsi_wait_scan not working (2.6.30.5) 2009-08-25 23:15 ` Alan Stern @ 2009-08-29 23:27 ` Arkadiusz Miskiewicz 2009-08-30 3:07 ` Alan Stern 0 siblings, 1 reply; 14+ messages in thread From: Arkadiusz Miskiewicz @ 2009-08-29 23:27 UTC (permalink / raw) To: Alan Stern; +Cc: James Bottomley, linux-scsi, Arjan van de Ven On Wednesday 26 of August 2009, Alan Stern wrote: > On Tue, 25 Aug 2009, Arkadiusz Miskiewicz wrote: > > On Tuesday 25 of August 2009, Arkadiusz Miskiewicz wrote: > > > On Tuesday 25 of August 2009, you wrote: > > > > On Tue, 2009-08-25 at 21:44 +0200, Arkadiusz Miskiewicz wrote: > > > > > On Tuesday 25 of August 2009, James Bottomley wrote: > > > > > > On Tue, 2009-08-25 at 21:24 +0200, Arkadiusz Miskiewicz wrote: > > > > > > > What could be the reason for scsi_wait_scan not waiting untill > > > > > > > all disks are found? > > > > > > > > > > > > > > I'm testing 2.6.30.5 on hardware with LSI Logic / Symbios Logic > > > > > > > MegaRAID 530 SCSI 320-0X RAID controller and modprobe > > > > > > > scsi_wait_scan finishes earlier than disks are found. > > > > > > > > > > > > > > My initrd (romfs) does: > > > > > > > insmod > > > > > > > /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/scsi_mod.ko > > > > > > > insmod > > > > > > > /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/megaraid/megaraid > > > > > > >_mm. ko insmod > > > > > > > /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/megaraid/megaraid > > > > > > >_mbo x. ko insmod > > > > > > > /lib/modules/2.6.30.5-0.3/kernel/lib/crc-t10dif.ko insmod > > > > > > > /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/sd_mod.ko insmod > > > > > > > /lib/modules/2.6.30.5-0.3/kernel/drivers/scsi/scsi_wait_scan.ko > > > > > > > insmod /lib/modules/2.6.30.5-0.3/kernel/fs/exportfs/exportfs.ko > > > > > > > insmod /lib/modules/2.6.30.5-0.3/kernel/fs/xfs/xfs.ko > > > > > > > if [ "${ROOT##/dev/}" != "${ROOT}" ]; then > > > > > > > rootnr="$(busybox awk -v rootnode="${ROOT##/dev/}" '$4 == > > > > > > > rootnode { print 256 * $1 + $2 }' /proc/partitions)" > > > > > > > if [ -n "$rootnr" ]; then > > > > > > > echo "$rootnr" > /proc/sys/kernel/real-root-dev > > > > > > > fi > > > > > > > > > > > > > > > > > > > > > Now if I add sleep few seconds or /bin/sh at the end of this > > > > > > > initrd, then boot and then disks are detected properly and > > > > > > > rootfs is mounted properly (after I exit from sh in case when > > > > > > > /bin/sh is used). > > > > > > > > > > > > > > The question remains - why scsi_wait_scan doesn't wait? > > > > > > > > > > > > It's caused by the sd async patches. What's happening is > > > > > > wait_scan is waiting until all the scans are complete, but now sd > > > > > > attachment may not be completed by the time that happens. So, > > > > > > although you have a scanned disk, you can't mount it without and > > > > > > attached sd driver. > > > > > > > > > > > > Hopefully when > > > > > > all initrds are configured to wait until root appears, this > > > > > > problem will go away. > > > > > > > > > > Uh, ugly. I'll disable SCSI_SCAN_ASYNC here then. > > > > > > > > That won't actually help: the sd async scan is a separate mechanism > > > > not tied to that variable > > > > > > I assume there is no configurable way to disable this? > > > > I found this patch > > > > http://marc.info/?l=linux-scsi&m=124388639906873&w=2 > > > > but it doesn't work on 30.5 (it's still not waiting untill everything is > > discovered) > > Did you remember to rebuild your initrd after applying this patch and > rebuilding the module? Patch was applied and module rebuilt. I'm 100% sure since I added printks to confirm (not included below). > > Can you provide the dmesg log showing what happens during bootup with > the patch applied? Hm, can console= point to netconsole somehow, so userspace messages could be seen via netconsole? Anyway from netconsole: Aug 30 01:07:16 rhea 13.144139] netconsole: network logging started Aug 30 01:07:16 rhea 13.173297] SCSI subsystem initialized Aug 30 01:07:16 rhea 13.189630] megaraid cmm: 2.20.2.7 (Release Date: Sun Jul 16 00:01:03 EST 2006) Aug 30 01:07:16 rhea 13.216688] megaraid: 2.20.5.1 (Release Date: Thu Nov 16 15:32:35 EST 2006) Aug 30 01:07:16 rhea 13.238942] megaraid: probe new device 0x1000:0x0407:0x1000:0x0530: Aug 30 01:07:16 rhea bus: 2:slot 3:func 0 Aug 30 01:07:16 rhea 13.271180] megaraid 0000:02:03.0: PCI INT A -> GSI 27 (level, low) -> IRQ 27 Aug 30 01:07:16 rhea 13.316707] megaraid: fw version:[414G] bios version:[A100] Aug 30 01:07:16 rhea 13.334528] scsi0 : LSI Logic MegaRAID driver Aug 30 01:07:16 rhea 13.352156] scsi[0]: scanning scsi channel 0 [Phy 0] Aug 30 01:07:16 rhea for: non-raid devices Aug 30 01:07:16 rhea 13.381065] Driver 'sd' needs updating - please use bus_type methods Aug 30 01:07:16 rhea 13.420430] SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled Aug 30 01:07:16 rhea 13.453259] SGI XFS Quota Management subsystem Aug 30 01:07:16 rhea 13.583779] VFS: Cannot open root device "802" or unknown-block(8,2) Aug 30 01:07:16 rhea 13.602814] Please append a correct "root=" boot option; here are the available partitions: Aug 30 01:07:16 rhea 13.627824] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,2) Aug 30 01:07:16 rhea 13.652637] Pid: 1, comm: swapper Not tainted 2.6.30.5-vs2.3.0.36.14-pre7-0.3 #4 Aug 30 01:07:16 rhea 13.674797] Call Trace: Aug 30 01:07:16 rhea 13.682138] [<ffffffff8056e75d>] ? panic+0x7a/0x12e Aug 30 01:07:16 rhea 13.697003] [<ffffffff8056e851>] ? printk+0x40/0x47 Aug 30 01:07:16 rhea 13.711890] [<ffffffff8072e090>] ? mount_block_root+0x1d6/0x271 Aug 30 01:07:16 rhea 13.729892] [<ffffffff8072ecdb>] ? initrd_load+0x228/0x324 Aug 30 01:07:16 rhea 13.746585] [<ffffffff8072e24f>] ? prepare_namespace+0xd5/0x18d Aug 30 01:07:16 rhea 13.764578] [<ffffffff8072d6cf>] ? kernel_init+0x178/0x188 Aug 30 01:07:16 rhea 13.781282] [<ffffffff8020ceba>] ? child_rip+0xa/0x20 Aug 30 01:07:16 rhea 13.796686] [<ffffffff8072d557>] ? kernel_init+0x0/0x188 Aug 30 01:07:16 rhea 13.812858] [<ffffffff8020ceb0>] ? child_rip+0x0/0x20 Aug 30 01:07:16 rhea 13.828253] Rebooting in 60 seconds and from ipmi console (this one is totally trashed, ipm console is crap in this machine) [ 2.080325] Block layer SCSI generic (bsg) drive550 driver, 4 ports, IRQ sharing enabled [ 2.553445] serial8250: ttyS0 at I/O 0x3f8 (irq = 4input/input0 [ 2.950179] Fixed MDIO Bus: probed [ 2.960632] PNP: PS/2 Controller [PNP030er [ 3.097910] cpuidle: using governor menu [ 3.109941] TCP cubic registered [ 3.120MDISK: gzip image found at block 0 [ 3.415767] VFS: Mounted root (romfs filesystem) readonlylow) -> IRQ 55 [ 4.148743] e1000: 0000:03:04.1: e1000_probe: (PCI-X:100MHz:64-bit) 00:04:23:[ 4.353818] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 6.934118] e1000: eth0 NIC Linkraid: 2.20.5.1 (Release Date: Thu Nov 16 15:32:35 EST 2006) dules/2.6.30.5-v[ 13.238942] megas/scsi/meg[ 13.352156] scsi[0]: scanning scsi channel 0 [Phy 0] for non-raid devices araid/menel/drivers/scsi/scsi_wait_scan.ko + insmod /lib/modules/2.6.30.5-vs2.3.0.36.14-pre7-0.3/kernelng: VFS: Unable to mount root fs on unknown-block(8,2) [ 13.652637] Pid: 1, comm: swapper Not [<ffffffff8072d6cf>] ? kernel_init+0x178/0x188 [ 13.781282] [<ffffffff8020ceba>] ? child_r initrd was doing: ... insmod /lib/modules/2.6.30.5-vs2.3.0.36.14-pre7-0.3/kernel/drivers/net/e1000/e1000.ko insmod /lib/modules/2.6.30.5-vs2.3.0.36.14-pre7-0.3/kernel/fs/configfs/configfs.ko insmod /lib/modules/2.6.30.5-vs2.3.0.36.14-pre7-0.3/kernel/drivers/net/netconsole.ko netconsole=xxx insmod /lib/modules/2.6.30.5-vs2.3.0.36.14-pre7-0.3/kernel/drivers/scsi/scsi_mod.ko insmod /lib/modules/2.6.30.5-vs2.3.0.36.14-pre7-0.3/kernel/drivers/scsi/megaraid/megaraid_mm.ko insmod /lib/modules/2.6.30.5-vs2.3.0.36.14-pre7-0.3/kernel/drivers/scsi/megaraid/megaraid_mbox.ko insmod /lib/modules/2.6.30.5-vs2.3.0.36.14-pre7-0.3/kernel/lib/crc-t10dif.ko insmod /lib/modules/2.6.30.5-vs2.3.0.36.14-pre7-0.3/kernel/drivers/scsi/sd_mod.ko insmod /lib/modules/2.6.30.5-vs2.3.0.36.14-pre7-0.3/kernel/drivers/scsi/scsi_wait_scan.ko insmod /lib/modules/2.6.30.5-vs2.3.0.36.14-pre7-0.3/kernel/fs/exportfs/exportfs.ko insmod /lib/modules/2.6.30.5-vs2.3.0.36.14-pre7-0.3/kernel/fs/xfs/xfs.ko ... and of course adding sleep 10 after scsi_wait_scan fixes boot > > Alan Stern -- Arkadiusz Miśkiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: scsi_wait_scan not working (2.6.30.5) 2009-08-29 23:27 ` Arkadiusz Miskiewicz @ 2009-08-30 3:07 ` Alan Stern 2009-08-30 8:12 ` Arkadiusz Miskiewicz 0 siblings, 1 reply; 14+ messages in thread From: Alan Stern @ 2009-08-30 3:07 UTC (permalink / raw) To: Arkadiusz Miskiewicz; +Cc: James Bottomley, linux-scsi, Arjan van de Ven On Sun, 30 Aug 2009, Arkadiusz Miskiewicz wrote: > > Can you provide the dmesg log showing what happens during bootup with > > the patch applied? > > Hm, can console= point to netconsole somehow, so userspace messages could be seen > via netconsole? Anyway from netconsole: > > Aug 30 01:07:16 rhea 13.144139] netconsole: network logging started > Aug 30 01:07:16 rhea 13.173297] SCSI subsystem initialized > Aug 30 01:07:16 rhea 13.189630] megaraid cmm: 2.20.2.7 (Release Date: Sun Jul 16 00:01:03 EST 2006) > Aug 30 01:07:16 rhea 13.216688] megaraid: 2.20.5.1 (Release Date: Thu Nov 16 15:32:35 EST 2006) > Aug 30 01:07:16 rhea 13.238942] megaraid: probe new device 0x1000:0x0407:0x1000:0x0530: > Aug 30 01:07:16 rhea bus: 2:slot 3:func 0 > Aug 30 01:07:16 rhea 13.271180] megaraid 0000:02:03.0: PCI INT A -> GSI 27 (level, low) -> IRQ 27 > Aug 30 01:07:16 rhea 13.316707] megaraid: fw version:[414G] bios version:[A100] > Aug 30 01:07:16 rhea 13.334528] scsi0 : LSI Logic MegaRAID driver > Aug 30 01:07:16 rhea 13.352156] scsi[0]: scanning scsi channel 0 [Phy 0] > Aug 30 01:07:16 rhea for: non-raid devices > Aug 30 01:07:16 rhea 13.381065] Driver 'sd' needs updating - please use bus_type methods > Aug 30 01:07:16 rhea 13.420430] SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled > Aug 30 01:07:16 rhea 13.453259] SGI XFS Quota Management subsystem > Aug 30 01:07:16 rhea 13.583779] VFS: Cannot open root device "802" or unknown-block(8,2) > Aug 30 01:07:16 rhea 13.602814] Please append a correct "root=" boot option; here are the available partitions: > Aug 30 01:07:16 rhea 13.627824] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,2) > Aug 30 01:07:16 rhea 13.652637] Pid: 1, comm: swapper Not tainted 2.6.30.5-vs2.3.0.36.14-pre7-0.3 #4 > Aug 30 01:07:16 rhea 13.674797] Call Trace: > Aug 30 01:07:16 rhea 13.682138] [<ffffffff8056e75d>] ? panic+0x7a/0x12e > Aug 30 01:07:16 rhea 13.697003] [<ffffffff8056e851>] ? printk+0x40/0x47 > Aug 30 01:07:16 rhea 13.711890] [<ffffffff8072e090>] ? mount_block_root+0x1d6/0x271 > Aug 30 01:07:16 rhea 13.729892] [<ffffffff8072ecdb>] ? initrd_load+0x228/0x324 > Aug 30 01:07:16 rhea 13.746585] [<ffffffff8072e24f>] ? prepare_namespace+0xd5/0x18d > Aug 30 01:07:16 rhea 13.764578] [<ffffffff8072d6cf>] ? kernel_init+0x178/0x188 > Aug 30 01:07:16 rhea 13.781282] [<ffffffff8020ceba>] ? child_rip+0xa/0x20 > Aug 30 01:07:16 rhea 13.796686] [<ffffffff8072d557>] ? kernel_init+0x0/0x188 > Aug 30 01:07:16 rhea 13.812858] [<ffffffff8020ceb0>] ? child_rip+0x0/0x20 > Aug 30 01:07:16 rhea 13.828253] Rebooting in 60 seconds > ... > > and of course adding sleep 10 after scsi_wait_scan fixes boot Not especially helpful, I'm afraid. If you could add some extra printk statements, it would be better. For example, you might add some KERN_INFO messages to sd.c at the start of sd_probe(), just before the async_schedule() call near the end, and at the start of sd_probe_async(). In addition, some messages demarking the various steps of wait_scan_init() in scsi_wait_scan.c would be good. Let's see what these messages produce both with and without the "sleep 10" in your initrd. Alan Stern ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: scsi_wait_scan not working (2.6.30.5) 2009-08-30 3:07 ` Alan Stern @ 2009-08-30 8:12 ` Arkadiusz Miskiewicz 2009-08-30 17:21 ` Alan Stern 0 siblings, 1 reply; 14+ messages in thread From: Arkadiusz Miskiewicz @ 2009-08-30 8:12 UTC (permalink / raw) To: Alan Stern; +Cc: James Bottomley, linux-scsi, Arjan van de Ven On Sunday 30 of August 2009, Alan Stern wrote: > On Sun, 30 Aug 2009, Arkadiusz Miskiewicz wrote: > > > Can you provide the dmesg log showing what happens during bootup with > > > the patch applied? > > > > Hm, can console= point to netconsole somehow, so userspace messages could > > be seen via netconsole? Anyway from netconsole: > > > > Aug 30 01:07:16 rhea 13.144139] netconsole: network logging started > > Aug 30 01:07:16 rhea 13.173297] SCSI subsystem initialized > > Aug 30 01:07:16 rhea 13.189630] megaraid cmm: 2.20.2.7 (Release Date: > > Sun Jul 16 00:01:03 EST 2006) Aug 30 01:07:16 rhea 13.216688] megaraid: > > 2.20.5.1 (Release Date: Thu Nov 16 15:32:35 EST 2006) Aug 30 01:07:16 > > rhea 13.238942] megaraid: probe new device 0x1000:0x0407:0x1000:0x0530: > > Aug 30 01:07:16 rhea bus: 2:slot 3:func 0 > > Aug 30 01:07:16 rhea 13.271180] megaraid 0000:02:03.0: PCI INT A -> GSI > > 27 (level, low) -> IRQ 27 Aug 30 01:07:16 rhea 13.316707] megaraid: fw > > version:[414G] bios version:[A100] Aug 30 01:07:16 rhea 13.334528] > > scsi0 : LSI Logic MegaRAID driver Aug 30 01:07:16 rhea 13.352156] > > scsi[0]: scanning scsi channel 0 [Phy 0] Aug 30 01:07:16 rhea for: > > non-raid devices > > Aug 30 01:07:16 rhea 13.381065] Driver 'sd' needs updating - please use > > bus_type methods Aug 30 01:07:16 rhea 13.420430] SGI XFS with ACLs, > > security attributes, large block/inode numbers, no debug enabled Aug 30 > > 01:07:16 rhea 13.453259] SGI XFS Quota Management subsystem Aug 30 > > 01:07:16 rhea 13.583779] VFS: Cannot open root device "802" or > > unknown-block(8,2) Aug 30 01:07:16 rhea 13.602814] Please append a > > correct "root=" boot option; here are the available partitions: Aug 30 > > 01:07:16 rhea 13.627824] Kernel panic - not syncing: VFS: Unable to > > mount root fs on unknown-block(8,2) Aug 30 01:07:16 rhea 13.652637] > > Pid: 1, comm: swapper Not tainted 2.6.30.5-vs2.3.0.36.14-pre7-0.3 #4 Aug > > 30 01:07:16 rhea 13.674797] Call Trace: > > Aug 30 01:07:16 rhea 13.682138] [<ffffffff8056e75d>] ? > > panic+0x7a/0x12e Aug 30 01:07:16 rhea 13.697003] [<ffffffff8056e851>] > > ? printk+0x40/0x47 Aug 30 01:07:16 rhea 13.711890] > > [<ffffffff8072e090>] ? mount_block_root+0x1d6/0x271 Aug 30 01:07:16 rhea > > 13.729892] [<ffffffff8072ecdb>] ? initrd_load+0x228/0x324 Aug 30 > > 01:07:16 rhea 13.746585] [<ffffffff8072e24f>] ? > > prepare_namespace+0xd5/0x18d Aug 30 01:07:16 rhea 13.764578] > > [<ffffffff8072d6cf>] ? kernel_init+0x178/0x188 Aug 30 01:07:16 rhea > > 13.781282] [<ffffffff8020ceba>] ? child_rip+0xa/0x20 Aug 30 01:07:16 > > rhea 13.796686] [<ffffffff8072d557>] ? kernel_init+0x0/0x188 Aug 30 > > 01:07:16 rhea 13.812858] [<ffffffff8020ceb0>] ? child_rip+0x0/0x20 Aug > > 30 01:07:16 rhea 13.828253] Rebooting in 60 seconds > > > > ... > > > > and of course adding sleep 10 after scsi_wait_scan fixes boot > > Not especially helpful, I'm afraid. If you could add some extra printk > statements, it would be better. For example, you might add some > KERN_INFO messages to sd.c at the start of sd_probe(), just before the > async_schedule() call near the end, and at the start of > sd_probe_async(). In addition, some messages demarking the various > steps of wait_scan_init() in scsi_wait_scan.c would be good. Aug 30 10:05:41 rhea 13.342770] netconsole: network logging started Aug 30 10:05:41 rhea 13.372165] SCSI subsystem initialized Aug 30 10:05:41 rhea 13.386641] megaraid cmm: 2.20.2.7 (Release Date: Sun Jul 16 00:01:03 EST 2006) Aug 30 10:05:41 rhea 13.414015] megaraid: 2.20.5.1 (Release Date: Thu Nov 16 15:32:35 EST 2006) Aug 30 10:05:41 rhea 13.436123] megaraid: probe new device 0x1000:0x0407:0x1000:0x0530: Aug 30 10:05:41 rhea bus: 2:slot 3:func 0 Aug 30 10:05:41 rhea 13.468399] megaraid 0000:02:03.0: PCI INT A -> GSI 27 (level, low) -> IRQ 27 Aug 30 10:05:41 rhea 13.516699] megaraid: fw version:[414G] bios version:[A100] Aug 30 10:05:41 rhea 13.535997] scsi0 : LSI Logic MegaRAID driver Aug 30 10:05:41 rhea 13.553565] scsi[0]: scanning scsi channel 0 [Phy 0] Aug 30 10:05:41 rhea for: non-raid devices Aug 30 10:05:41 rhea 13.586494] Driver 'sd' needs updating - please use bus_type methods Aug 30 10:05:41 rhea 13.607265] wait_scan_init: BEFORE wait_for_device_probe Aug 30 10:05:41 rhea 13.625998] wait_scan_init: AFTER wait_for_device_probe Aug 30 10:05:41 rhea 13.645813] wait_scan_init: BEFORE scsi_complete_async_scans Aug 30 10:05:41 rhea 13.666926] wait_scan_init: AFTER scsi_complete_async_scans Aug 30 10:05:41 rhea 13.687750] wait_scan_init: BEFORE async_synchronize_full Aug 30 10:05:41 rhea 13.708100] wait_scan_init: AFTER wait_for_device_probe Aug 30 10:05:42 rhea 13.973100] SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled Aug 30 10:05:42 rhea 14.005223] SGI XFS Quota Management subsystem Aug 30 10:05:42 rhea 14.093763] VFS: Cannot open root device "802" or unknown-block(8,2) Aug 30 10:05:42 rhea 14.112812] Please append a correct "root=" boot option; here are the available partitions: Aug 30 10:05:42 rhea 14.137870] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,2) Aug 30 10:05:42 rhea 14.140707] scsi 0:0:6:0: Processor ESG-SHV SCA HSBP M29 1.08 PQ: 0 ANSI: 2 Aug 30 10:05:42 rhea 14.186854] Pid: 1, comm: swapper Not tainted 2.6.30.5-vs2.3.0.36.14-pre7-0.3 #4 Aug 30 10:05:42 rhea 14.209012] Call Trace: Aug 30 10:05:42 rhea 14.216352] [<ffffffff8056e75d>] ? panic+0x7a/0x12e Aug 30 10:05:42 rhea 14.231214] [<ffffffff8056e851>] ? printk+0x40/0x47 Aug 30 10:05:42 rhea 14.246097] [<ffffffff8072e090>] ? mount_block_root+0x1d6/0x271 Aug 30 10:05:42 rhea 14.264099] [<ffffffff8072ecdb>] ? initrd_load+0x228/0x324 Aug 30 10:05:42 rhea 14.280790] [<ffffffff8072e24f>] ? prepare_namespace+0xd5/0x18d Aug 30 10:05:42 rhea 14.298777] [<ffffffff8072d6cf>] ? kernel_init+0x178/0x188 Aug 30 10:05:42 rhea 14.315481] [<ffffffff8020ceba>] ? child_rip+0xa/0x20 Aug 30 10:05:42 rhea 14.330885] [<ffffffff8072d557>] ? kernel_init+0x0/0x188 Aug 30 10:05:42 rhea 14.347077] [<ffffffff8020ceb0>] ? child_rip+0x0/0x20 Aug 30 10:05:42 rhea 14.362470] Rebooting in 60 seconds.. > > Let's see what these messages produce both with and without the "sleep > 10" in your initrd. with sleep Aug 30 11:11:52 rhea kernel: [ 6.950127] console [netcon0] enabled Aug 30 11:11:52 rhea kernel: [ 13.116253] netconsole: network logging started Aug 30 11:11:52 rhea kernel: [ 13.145344] SCSI subsystem initialized Aug 30 11:11:52 rhea kernel: [ 13.160103] megaraid cmm: 2.20.2.7 (Release Date: Sun Jul 16 00:01:03 EST 2006) Aug 30 11:11:52 rhea kernel: [ 13.187529] megaraid: 2.20.5.1 (Release Date: Thu Nov 16 15:32:35 EST 2006) Aug 30 11:11:52 rhea kernel: [ 13.209685] megaraid: probe new device 0x1000:0x0407:0x1000:0x0530: bus 2:slot 3:func 0 Aug 30 11:11:52 rhea kernel: [ 13.241872] alloc irq_desc for 27 on cpu 0 node 0 Aug 30 11:11:52 rhea kernel: [ 13.241876] alloc kstat_irqs on cpu 0 node 0 Aug 30 11:11:52 rhea kernel: [ 13.241885] megaraid 0000:02:03.0: PCI INT A -> GSI 27 (level, low) -> IRQ 27 Aug 30 11:11:52 rhea kernel: [ 13.286708] megaraid: fw version:[414G] bios version:[A100] Aug 30 11:11:52 rhea kernel: [ 13.305284] scsi0 : LSI Logic MegaRAID driver Aug 30 11:11:52 rhea kernel: [ 13.322942] scsi[0]: scanning scsi channel 0 [Phy 0] for non-raid devices Aug 30 11:11:52 rhea kernel: [ 13.355882] Driver 'sd' needs updating - please use bus_type methods Aug 30 11:11:52 rhea kernel: [ 13.379162] wait_scan_init: BEFORE wait_for_device_probe Aug 30 11:11:52 rhea kernel: [ 13.397928] wait_scan_init: AFTER wait_for_device_probe Aug 30 11:11:52 rhea kernel: [ 13.417739] wait_scan_init: BEFORE scsi_complete_async_scans Aug 30 11:11:52 rhea kernel: [ 13.438822] wait_scan_init: AFTER scsi_complete_async_scans Aug 30 11:11:52 rhea kernel: [ 13.459688] wait_scan_init: BEFORE async_synchronize_full Aug 30 11:11:52 rhea kernel: [ 13.479998] wait_scan_init: AFTER wait_for_device_probe Aug 30 11:11:52 rhea kernel: [ 13.902193] scsi 0:0:6:0: Processor ESG-SHV SCA HSBP M29 1.08 PQ: 0 ANSI: 2 Aug 30 11:11:52 rhea kernel: [ 15.930664] scsi[0]: scanning scsi channel 1 [Phy 1] for non-raid devices Aug 30 11:11:52 rhea kernel: [ 19.706530] scsi[0]: scanning scsi channel 2 [virtual] for logical drives Aug 30 11:11:52 rhea kernel: [ 19.727104] scsi 0:2:0:0: Direct-Access MegaRAID LD 0 RAID5 280G 414G PQ: 0 ANSI: 2 Aug 30 11:11:52 rhea kernel: [ 19.757564] sd_probe: BEFORE async_schedule Aug 30 11:11:52 rhea kernel: [ 19.770091] sd_probe: AFTER async_schedule Aug 30 11:11:52 rhea kernel: [ 19.782507] sd_probe_async: ENTERED Aug 30 11:11:52 rhea kernel: [ 19.793223] sd 0:2:0:0: [sda] 574218240 512-byte hardware sectors: (293 GB/273 GiB) Aug 30 11:11:52 rhea kernel: [ 19.816173] sd 0:2:0:0: [sda] Write Protect is off Aug 30 11:11:52 rhea kernel: [ 19.830525] sd 0:2:0:0: [sda] Mode Sense: 00 00 00 00 Aug 30 11:11:52 rhea kernel: [ 19.830549] sd 0:2:0:0: [sda] Asking for cache data failed Aug 30 11:11:52 rhea kernel: [ 19.846978] sd 0:2:0:0: [sda] Assuming drive cache: write through Aug 30 11:11:52 rhea kernel: [ 19.865496] sd 0:2:0:0: [sda] Asking for cache data failed Aug 30 11:11:52 rhea kernel: [ 19.881920] sd 0:2:0:0: [sda] Assuming drive cache: write through Aug 30 11:11:52 rhea kernel: [ 19.900198] sda: sda1 sda2 sda3 Aug 30 11:11:52 rhea kernel: [ 19.924019] sd 0:2:0:0: [sda] Attached SCSI disk Aug 30 11:11:52 rhea kernel: [ 23.113336] eth0: no IPv6 routers present Aug 30 11:11:52 rhea kernel: [ 23.754010] SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled Aug 30 11:11:52 rhea kernel: [ 23.786463] SGI XFS Quota Management subsystem Aug 30 11:11:52 rhea kernel: [ 23.915852] XFS mounting filesystem sda2 Aug 30 11:11:52 rhea kernel: [ 24.050956] Ending clean XFS mount for filesystem: sda2 Aug 30 11:11:52 rhea kernel: [ 24.051050] VFS: Mounted root (xfs filesystem) readonly on device 8:2. > > Alan Stern -- Arkadiusz Miśkiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: scsi_wait_scan not working (2.6.30.5) 2009-08-30 8:12 ` Arkadiusz Miskiewicz @ 2009-08-30 17:21 ` Alan Stern 0 siblings, 0 replies; 14+ messages in thread From: Alan Stern @ 2009-08-30 17:21 UTC (permalink / raw) To: Arkadiusz Miskiewicz; +Cc: James Bottomley, linux-scsi, Arjan van de Ven On Sun, 30 Aug 2009, Arkadiusz Miskiewicz wrote: > with sleep > > Aug 30 11:11:52 rhea kernel: [ 6.950127] console [netcon0] enabled > Aug 30 11:11:52 rhea kernel: [ 13.116253] netconsole: network logging started > Aug 30 11:11:52 rhea kernel: [ 13.145344] SCSI subsystem initialized > Aug 30 11:11:52 rhea kernel: [ 13.160103] megaraid cmm: 2.20.2.7 (Release Date: Sun Jul 16 00:01:03 EST 2006) > Aug 30 11:11:52 rhea kernel: [ 13.187529] megaraid: 2.20.5.1 (Release Date: Thu Nov 16 15:32:35 EST 2006) > Aug 30 11:11:52 rhea kernel: [ 13.209685] megaraid: probe new device 0x1000:0x0407:0x1000:0x0530: bus 2:slot 3:func 0 > Aug 30 11:11:52 rhea kernel: [ 13.241872] alloc irq_desc for 27 on cpu 0 node 0 > Aug 30 11:11:52 rhea kernel: [ 13.241876] alloc kstat_irqs on cpu 0 node 0 > Aug 30 11:11:52 rhea kernel: [ 13.241885] megaraid 0000:02:03.0: PCI INT A -> GSI 27 (level, low) -> IRQ 27 > Aug 30 11:11:52 rhea kernel: [ 13.286708] megaraid: fw version:[414G] bios version:[A100] > Aug 30 11:11:52 rhea kernel: [ 13.305284] scsi0 : LSI Logic MegaRAID driver > Aug 30 11:11:52 rhea kernel: [ 13.322942] scsi[0]: scanning scsi channel 0 [Phy 0] for non-raid devices > Aug 30 11:11:52 rhea kernel: [ 13.355882] Driver 'sd' needs updating - please use bus_type methods > Aug 30 11:11:52 rhea kernel: [ 13.379162] wait_scan_init: BEFORE wait_for_device_probe > Aug 30 11:11:52 rhea kernel: [ 13.397928] wait_scan_init: AFTER wait_for_device_probe > Aug 30 11:11:52 rhea kernel: [ 13.417739] wait_scan_init: BEFORE scsi_complete_async_scans > Aug 30 11:11:52 rhea kernel: [ 13.438822] wait_scan_init: AFTER scsi_complete_async_scans > Aug 30 11:11:52 rhea kernel: [ 13.459688] wait_scan_init: BEFORE async_synchronize_full > Aug 30 11:11:52 rhea kernel: [ 13.479998] wait_scan_init: AFTER wait_for_device_probe Note here that the wait finished before most of the probing was done. > Aug 30 11:11:52 rhea kernel: [ 13.902193] scsi 0:0:6:0: Processor ESG-SHV SCA HSBP M29 1.08 PQ: 0 ANSI: 2 > Aug 30 11:11:52 rhea kernel: [ 15.930664] scsi[0]: scanning scsi channel 1 [Phy 1] for non-raid devices > Aug 30 11:11:52 rhea kernel: [ 19.706530] scsi[0]: scanning scsi channel 2 [virtual] for logical drives > Aug 30 11:11:52 rhea kernel: [ 19.727104] scsi 0:2:0:0: Direct-Access MegaRAID LD 0 RAID5 280G 414G PQ: 0 ANSI: 2 > Aug 30 11:11:52 rhea kernel: [ 19.757564] sd_probe: BEFORE async_schedule > Aug 30 11:11:52 rhea kernel: [ 19.770091] sd_probe: AFTER async_schedule > Aug 30 11:11:52 rhea kernel: [ 19.782507] sd_probe_async: ENTERED > Aug 30 11:11:52 rhea kernel: [ 19.793223] sd 0:2:0:0: [sda] 574218240 512-byte hardware sectors: (293 GB/273 GiB) > Aug 30 11:11:52 rhea kernel: [ 19.816173] sd 0:2:0:0: [sda] Write Protect is off > Aug 30 11:11:52 rhea kernel: [ 19.830525] sd 0:2:0:0: [sda] Mode Sense: 00 00 00 00 > Aug 30 11:11:52 rhea kernel: [ 19.830549] sd 0:2:0:0: [sda] Asking for cache data failed > Aug 30 11:11:52 rhea kernel: [ 19.846978] sd 0:2:0:0: [sda] Assuming drive cache: write through > Aug 30 11:11:52 rhea kernel: [ 19.865496] sd 0:2:0:0: [sda] Asking for cache data failed > Aug 30 11:11:52 rhea kernel: [ 19.881920] sd 0:2:0:0: [sda] Assuming drive cache: write through > Aug 30 11:11:52 rhea kernel: [ 19.900198] sda: sda1 sda2 sda3 > Aug 30 11:11:52 rhea kernel: [ 19.924019] sd 0:2:0:0: [sda] Attached SCSI disk > Aug 30 11:11:52 rhea kernel: [ 23.113336] eth0: no IPv6 routers present > Aug 30 11:11:52 rhea kernel: [ 23.754010] SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled > Aug 30 11:11:52 rhea kernel: [ 23.786463] SGI XFS Quota Management subsystem > Aug 30 11:11:52 rhea kernel: [ 23.915852] XFS mounting filesystem sda2 > Aug 30 11:11:52 rhea kernel: [ 24.050956] Ending clean XFS mount for filesystem: sda2 > Aug 30 11:11:52 rhea kernel: [ 24.051050] VFS: Mounted root (xfs filesystem) readonly on device 8:2. Okay, this problem is not the one that patch you found was intended to solve. It may be caused by excessively long delays in the megaraid driver, or maybe megaraid uses extra kernel threads for its probing; I can't tell. Even more debugging info would help. Keep the new printk statements and try adding similar printks to the beginning and end of scsi_prep_async_scan() and scsi_finish_async_scan() in scsi_scan.c. That should tell us the relative timing of the async routines and the wait routines. In the end, I suspect you'll need to ask the author or maintainer of the megaraid driver for help solving this. Alan Stern ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: scsi_wait_scan not working (2.6.30.5) 2009-08-25 19:28 ` James Bottomley 2009-08-25 19:44 ` Arkadiusz Miskiewicz @ 2009-08-26 14:34 ` Chris Webb 2009-08-26 15:40 ` James Bottomley 1 sibling, 1 reply; 14+ messages in thread From: Chris Webb @ 2009-08-26 14:34 UTC (permalink / raw) To: James Bottomley; +Cc: Arkadiusz Miskiewicz, linux-scsi, Arjan van de Ven James Bottomley <James.Bottomley@suse.de> writes: > It's caused by the sd async patches. What's happening is wait_scan is > waiting until all the scans are complete, but now sd attachment may not > be completed by the time that happens. So, although you have a scanned > disk, you can't mount it without and attached sd driver. Hopefully when > all initrds are configured to wait until root appears, this problem will > go away. This change has been causing me some puzzlement working out the right way to do things in our infrastructure management code. Imagine I want a shell function which takes a host and target name and returns a device node name, ready to use. (In practice the login and logout functions would do reference counting to avoid multiple logins to the same target for different consumers, and set up device mapper targets and so on, but we can ignore that here.) Previously, because iscsiadm --login does the equivalent of echo - - - > /sys/class/scsi_host/hostX/scan it was sufficient for me to do udevadm settle and then something like shopt -s nullglob local SESSION TARGET SESSION BLOCK KERNEL for SESSION in /sys/class/scsi_host/host*/device/session*; do for TARGET in $SESSION/iscsi_session/*/targetname; do [ "`< "$TARGET"`" = "$1" ] || continue for BLOCK in "$SESSION"/target*/*/block/*; do KERNEL=${BLOCK##*/} echo /dev/$KERNEL return $SUCCESS done done done return $EMISSING to find my block device. Now I can't do that, and it's not obvious what the official way is to block until the outstanding async sd attachment has completed. Maybe I'm going about this completely the wrong way? Polling in a loop with a sleep isn't very nice, and clearly can't be how people are meant to do this, but everything else I've come up with is worse or more intrusive to the system. Cheers, Chris. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: scsi_wait_scan not working (2.6.30.5) 2009-08-26 14:34 ` Chris Webb @ 2009-08-26 15:40 ` James Bottomley 2009-08-26 16:23 ` Chris Webb 0 siblings, 1 reply; 14+ messages in thread From: James Bottomley @ 2009-08-26 15:40 UTC (permalink / raw) To: Chris Webb; +Cc: Arkadiusz Miskiewicz, linux-scsi, Arjan van de Ven [resending with cc list this time] On Wed, 2009-08-26 at 15:34 +0100, Chris Webb wrote: > James Bottomley <James.Bottomley@suse.de> writes: > > > It's caused by the sd async patches. What's happening is wait_scan is > > waiting until all the scans are complete, but now sd attachment may not > > be completed by the time that happens. So, although you have a scanned > > disk, you can't mount it without and attached sd driver. Hopefully when > > all initrds are configured to wait until root appears, this problem will > > go away. > > This change has been causing me some puzzlement working out the right way to do > things in our infrastructure management code. Imagine I want a shell function > which takes a host and target name and returns a device node name, ready to > use. (In practice the login and logout functions would do reference counting to > avoid multiple logins to the same target for different consumers, and set up > device mapper targets and so on, but we can ignore that here.) > > Previously, because iscsiadm --login does the equivalent of > > echo - - - > /sys/class/scsi_host/hostX/scan > > it was sufficient for me to do udevadm settle and then something like > > shopt -s nullglob > local SESSION TARGET SESSION BLOCK KERNEL > for SESSION in /sys/class/scsi_host/host*/device/session*; do > for TARGET in $SESSION/iscsi_session/*/targetname; do > [ "`< "$TARGET"`" = "$1" ] || continue > for BLOCK in "$SESSION"/target*/*/block/*; do > KERNEL=${BLOCK##*/} > echo /dev/$KERNEL > return $SUCCESS > done > done > done > return $EMISSING > > to find my block device. Now I can't do that, and it's not obvious what the > official way is to block until the outstanding async sd attachment has > completed. Maybe I'm going about this completely the wrong way? Polling in a > loop with a sleep isn't very nice, and clearly can't be how people are meant to > do this, but everything else I've come up with is worse or more intrusive to > the system. Right, polling isn't desirable. The way it's supposed to work is that you listen for the uevent that signals the sd binding is complete, so you actually get notice asynchronously. The event carries device information with it. udev uses the node information to send VPD inquiries, which is how it does the by-id and by-uuid mappings. James ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: scsi_wait_scan not working (2.6.30.5) 2009-08-26 15:40 ` James Bottomley @ 2009-08-26 16:23 ` Chris Webb 0 siblings, 0 replies; 14+ messages in thread From: Chris Webb @ 2009-08-26 16:23 UTC (permalink / raw) To: James Bottomley; +Cc: Arkadiusz Miskiewicz, linux-scsi, Arjan van de Ven James Bottomley <James.Bottomley@suse.de> writes: > The way it's supposed to work is that you listen for the uevent that > signals the sd binding is complete, so you actually get notice > asynchronously. The event carries device information with it. udev > uses the node information to send VPD inquiries, which is how it does > the by-id and by-uuid mappings. Quite hard to sit down and actually write a shell script to do this, though! It feels like the operation of logging into an iscsi target, waiting for the device node and then returning it is something you'd reasonably expect to be able to do, but it's become quite tricky in this async world. Netlink isn't at all accessible to scripts, and udevadm doesn't provide a good front-end to do it either. When something like a USB device being plugged in, the operation is fundamentally asynchronous, but with an iscsi login, the device is appearing because you've run a login command, so it's not completely mad to hope to be get back the ultimate result of that command, even if you have to wait for it. Cheers, Chris. ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2009-08-30 17:21 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-08-25 19:24 scsi_wait_scan not working (2.6.30.5) Arkadiusz Miskiewicz 2009-08-25 19:28 ` James Bottomley 2009-08-25 19:44 ` Arkadiusz Miskiewicz 2009-08-25 19:47 ` James Bottomley 2009-08-25 20:01 ` Arkadiusz Miskiewicz 2009-08-25 21:22 ` Arkadiusz Miskiewicz 2009-08-25 23:15 ` Alan Stern 2009-08-29 23:27 ` Arkadiusz Miskiewicz 2009-08-30 3:07 ` Alan Stern 2009-08-30 8:12 ` Arkadiusz Miskiewicz 2009-08-30 17:21 ` Alan Stern 2009-08-26 14:34 ` Chris Webb 2009-08-26 15:40 ` James Bottomley 2009-08-26 16:23 ` Chris Webb
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).