Linux on 390 Port <[email protected]> wrote on 2013-02-14 01:56:48: > From: > > Leland Lucius <[email protected]> > [..] > > > > Note that adding kernel/module parameter dasd=autodetect should achieve > > the same result. > > > That's really weird. We always specify dasd=autodetect. I even just > double checked to make sure. All of the disks are certainly detected, > they just don't come up online. >
As far as I understand your problem, you place the dasd=autodetect on the kernel parameter line, and it is ignored. You can get around this by specifying dasd_mod.dasd=... on the kernel parameter line instead of just dasd=... The explanaition why this works is a bit lengthy, so please bear with me :-) First you need to know that the kernel parameter and module parameter handling are two different mechanisms and use two different interfaces in the device driver. In particular this means that a driver that is build into the kernel will only see kernel parameters and a driver that is build as a module will only see module parameters. In the case of the dasd_mod module we accept 'dasd=...' both as kernel and as module parameter and run them through the same parser, but they are still two different interfaces. So if you specify the dasd=... kernel parameter, but the DASD device driver is build as a module (as it is on SLES11), then this parameter cannot be given via the kernel parameter interface to the device driver and is just ignored. Now, for a moment consider the other possible situation: You have a driver that is usually built as a module and only uses the module parameter interface. If you want to compile this driver into the kernel instead of a module then it will still not accept kernel parameters, as it does not implement that interface. To help with this kind of situation the kernel provides a syntax that allows you to specify module parameters on the kernel command line: <module name>.<module parameter>=... In theory that should not help us at all, since we need a way to pass something from the kernel command line to a module. But at this point modprobe comes into play: Newer versions of modprobe parse /proc/cmdline for module parameters that match a module you want to load and uses them. So if you specify dasd_mod.dasd=autodetect on the kernel command line of a SLES11 SP2, the following will happen: 1. The kernel will see dasd_mod.dasd=autodetect but since the DASD device driver is not built into the kernel, it will not do anything with it. 2. At a later point in time, when the code in the initrd uses modprobe to load the dasd_mod module, modprobe will see dasd_mod.dasd in /proc/cmdline and pass its parameter to dasd_mod. As you can see this is a very roundabout way to pass a module parameter to a module and it can easily break: - Is the modprobe version used by your distro new enough? - Is this behaviour of modprobe an official interface or can it just 'go away'? - What happens if a modprobe.conf specifies a dasd parameter as well? My own gut feeling says: Do not mess with the way a distribution does its configuration, unless you have a good reason to do so. So in general I do not recommend to use this trick in a production system. But on the other side it is nice to know how it works and can help you in tricky situations, e.g. as a temporary workaround for some problem. Mit freundlichen Grüßen / Kind regards Stefan Weinhuber -- Linux for zSeries kernel development IBM Systems &Technology Group, Systems Software Development / SW Linux für zSeries Entwicklung IBM Deutschland Schoenaicher Str. 220 71032 Boeblingen Phone: +49-7031-16-4018 E-Mail: [email protected] IBM Deutschland Research & Development GmbH / Vorsitzender des Aufsichtsrats: Martina Koederitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
