Bug#596015: initramfs-tools: provide support for scsi_wait_scan

2010-09-08 Thread maximilian attems
On Wed, 08 Sep 2010, Michael Prokop wrote:

 
 scsi_wait_scan is a kernel module that waits until all the async
 scans are complete.
 
 Debian kernel as well as the ones from other Debian based distros
 usually have this stuff compiled as a kernel module and not
 statically into the kernel (which is good, because under certain
 conditions scsi_wait_scan *could* fail maybe, and disabling the
 compiled in driver doesn't seem to be possible).

known.

~/src/initramfs-tools$ egrep scsi_wait_scan 
/usr/share/initramfs-tools/scripts/init-top/udev 
modprobe -q scsi_wait_scan  modprobe -r scsi_wait_scan || true

 
 I just got a bugreport against Grml, stating that Grml as well as
 Debian and Ubuntu Server fail to boot on recent IBM BladeCenter HS22
 hardware. Having scsi_wait_scan statically compiled into the kernel
 is known to fix this problem. Instead of going this approach I'd
 recommend to implement proper support for that in our i-t (which is
 also the way to go according to the module's source).

telling the admin to use rootdelay is the more sane approach.
as they'd be still using the updated and supported linux-2.6.
From such big boxes one can and should expect an educated admin.
 
 My recommendation is to run modprobe scsi_wait_scan by default and
 provide a bootoption like noscsiwait to skip this part if wanted.
 (Optionally we could also try to rmmod the module after a long period
 of time hanging in the init process, in case we notice that there
 *might* be problems with autoloading the module; though I'm not yet sure
 whether this would really work, haven't looked into the details yet).

we do.
 
 I would volunteer to implement that and provide an according Grml
 ISO with that feature to the bugreporter for proper testing.
 
 What do you think of that? maks?

the trouble is that scsi_wait_scan is not implemented across all
relevant scsi drivers, nor inside of any usb driver nor inside of libata.
There were old patches floating for the later on. They'd need
to be resurrected massaged and reposted. I'd assume that the
correct fix for aboves bug lies on linux-2.6 side.




-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100908093411.ga22...@stro.at



Bug#596015: initramfs-tools: provide support for scsi_wait_scan

2010-09-07 Thread Michael Prokop
Package: initramfs-tools
Version: 0.98.2
Severity: wishlist


scsi_wait_scan is a kernel module that waits until all the async
scans are complete.

Debian kernel as well as the ones from other Debian based distros
usually have this stuff compiled as a kernel module and not
statically into the kernel (which is good, because under certain
conditions scsi_wait_scan *could* fail maybe, and disabling the
compiled in driver doesn't seem to be possible).

I just got a bugreport against Grml, stating that Grml as well as
Debian and Ubuntu Server fail to boot on recent IBM BladeCenter HS22
hardware. Having scsi_wait_scan statically compiled into the kernel
is known to fix this problem. Instead of going this approach I'd
recommend to implement proper support for that in our i-t (which is
also the way to go according to the module's source).

My recommendation is to run modprobe scsi_wait_scan by default and
provide a bootoption like noscsiwait to skip this part if wanted.
(Optionally we could also try to rmmod the module after a long period
of time hanging in the init process, in case we notice that there
*might* be problems with autoloading the module; though I'm not yet sure
whether this would really work, haven't looked into the details yet).

I would volunteer to implement that and provide an according Grml
ISO with that feature to the bugreporter for proper testing.

What do you think of that? maks?

regards,
-mika-



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2010-09-08t00-55...@devnull.michael-prokop.at