From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 22 Mar 2006 11:00:03 +0200 From: Michael Shigorin To: devel@lists.altlinux.org Message-ID: <20060322090003.GD28577@osdn.org.ua> Mail-Followup-To: devel@lists.altlinux.org Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2.1i Subject: [devel] Fwd: Re: Discussion about UUID and ide-generic X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.7 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2006 09:01:03 -0000 Archived-At: List-Archive: List-Post: (вдогонку) ----- Forwarded message from Scott James Remnant ----- Date: Tue, 21 Mar 2006 19:41:44 +0000 From: Scott James Remnant To: ubuntu-devel-announce/lists.ubuntu.com Subject: Re: Discussion about UUID and ide-generic On Tue, 2006-03-21 at 11:00 -0500, Ben Collins wrote: > This was a lengthy discussion that actually touched on two subjects. > Sorry I missed this discussion, I was offline all afternoon testing NM and other network-related issues. We just had an additional discussion about this, attached: BenC_: so it appears I missed a discussion this afternoon? Keybuk: appears so :) BenC_: which is a shame, because your conclusions were all wrong * Keybuk wishes someone had phoned him anyway, am replying now via e-mail I don't recall having any conclusions "wait 10s before loading ide-generic" that's not a conclusion, that's a suggestion :) it's a decision, according to your e-mail based on Mith's argument it won't help a monkey's the kernel already has that "sleep 10" in the IDE init code which is in the module loading bit so blocks the return of modprobe but if the module load is blocking, so are all other modules "all other modules" ? I didn't know ide-generic had a sleep(10) i it ide-generic doesn't or is this ide-core? every IDE driver does ide-core modprobe real-pci-driver consistently doesn't return until udev has the events is this the "Probing later" thing? it can take a few seconds to return on most things I don't know what "probing later" is are you sure you read Mith's arguments that promoted me suggesting that? prompted * BenC has quit (Connection timed out) he statement was that the main reason we don't use UUID more widely is that it has some dependency on the bus type right and the sleep 10 won't change that it doesn't have a dependency on the bus type this is the bit where me being there would have helped he stated differently ok, so here's how the initramfs bits work first we look at the ROOT= to detect the bus type either IDE or "everything else" (which are always scsi) then it does have code that depends on ide or !ide Keybuk: Eh? That's entirely untrue, as far as I can tell All the drivers under the scsi subsystem (which includes sata, usb, firewire) behave one way Keybuk: I can't find any sign of a sleep(10) in the ide-generic load path the modprobe returns immediately, then at some point in the future the driver finds its devices mjg59: not a literal sleep(10); not ide-generic; the ide-core probes and binds for the REAL PCI DRIVERS before modprobe can return Keybuk: How? mjg59: please let me finish first ok, so for scsi and friends; we have to iterate the bus, modprobe all the drivers, then sit back and wait for the devices to show up * BenC_ is now known as BenC sit back and wait up to three minutes for especially slow scsi controllers (fabbione delights in owning these) so we do it with a simple while loop; while the root device hasn't shown up on disc, sleep another tenth of a second if it at the end of that loop, the root device still hasn't shown up, we give up ok, the ide portion is more important :) for dapper+1 I'd like to extend that to "wait forever", and have some pretty on screen message saying something along the lines of "if your root disk isn't plugged in, could you do that?" so that's scsi ide we do it differently, because the ide subsystem has different quirks the drivers behave the other way, the modprobe doesn't return until the driver has done the probe-and-bind there's no asynchronous component to them we also may have to load ide-generic on legacy ISA machines and in some cases with a root device on an ancient PCMCIA controller (which counts as "legacy ISA" in my mind) Keybuk: I'm still not finding anywhere where the PCI IDE drivers differ from normal PCI drivers (where there is an asynchronous component) Hm. PCMCIA ought to come under pcmcia_cs Uh, ide_cs regular PCI IDE drivers use pci probing, and normal device layer callbacks pcmcia bridges are not incl. in latest initramfs by default mjg59: critical path. the ide core already knows what devices are available. so there's no issuing of a probe command, and waiting for it to return. it just iterates an already-in-memory structure and does the magic There's a corner case where it's not actually PCMCIA, but an on-board IDE interface is connected via the PMCIA slot the difference is that IDE detects the drives at the same time it detects the controllers so Keybuk is correct in how it works right if you detect the controller, you also just detected the drives how do you decide to load ide-generic? scsi after detecting the controller you have to ask the controller nicely to go detect the drives and get back to you on that right so because of the way ide works in this regard, what we do is iterate each PCI device in order, and load the module for it, waiting for everything to settle in between Keybuk: You load piix. That registers itself as an IDE driver, which in turn calls pci_register_driver. After pci_register_driver, the probe routine in piix (piix_init_one) is called. If that binds to something, it does ide_setup_pci_device (which actually allocates the interface) mjg59: right, nothing there returns to userspace Isn't that exactly the same as loading a network driver, except that pci_register_device is done in the IDE layer rather than in the module itself? thanks for verifying that for us :) so we know after we've loaded the PCI drivers, if the root device still hasn't shown up, it isn't going to show up later so we load ide-generic as a last resort scsi looks like "load drivers; wait for root device to show up; abort after 3 minutes" ide looks like "load drivers sequentially; if root device hasn't shown up, load ide-generic" So the original discussion appears to have been based on the false premise that we need to know whether the root device is on ide or not in order to only load ide-generic at the appropriate time? well, no * mxpxpod (n=bryan@unaffiliated/mxpxpod) has joined #ubuntu-kernel we still need to know whether we may or may not need to load ide-generic no, it's correct the only incorrect info I got was the loading ide-generic was racy and could cause problems Why not load scsi drivers first, then ide drivers (at this point based on PCI IDs), then unconditionally load ide-generic if there's still no rootfs? Loading ide-generic isn't going to hurt in the case where the PCI driver has already bound the io-ports mjg59: because of FUCKING SATA Keybuk: But you've already loaded the driver SATA as far as I'm concerned is a scsi driver mjg59: according to Mith, Fabio's crappy scsi controller breaks if you load ide-generic it behaves like scsi drivers most importantly, it returns from modprobe immediately, before performing the controller-specific initialisation so modprobe piix-sata will return straight away, and udev will get the devices some few seconds later on some older SATA controllers, on a busy system, this can be 10-15s Keybuk: ok, here's the problems I see.... loading ide-generic at any point before the SATA SCSI driver has finished can sometimes "steal" the devices from it the solution wwould be to only load ide-generic after the three minutes are up which means everyone on ISA would have to wait 3 minutes before their machine started booting Keybuk: ata_piix calls piix_init, which calls pci_module_init, which will then provide a probe method which registers the pors Keybuk: IMO, we should detect that ide-generic is needed at install, and make a note of it for initramfs to use :) Keybuk: I'm still not seeing how this is different to the IDE case (though there may be something very simple I'm missing) or when initramfs is built, it could detect that mjg59: right, and then it returns to userspace, and libata later calls the probe method BenC: I agree. We can look in /sys in the installer and see whether the driver is ide-generic or not; if not, use UUID Keybuk: Sorry, /which/ probe method? mjg59: I can't remember offhand; when I looked through the code (a few months ago) the SATA stuff was very much callback orientated and hooked into the SCSI bits of the kernel which are totally async mjg59: from what I can tell, scsi device probing happens in the scsiX kernel process and not in the module probe code path whereas IDE was all one obvious line of function call codes BenC: What are you defining as "scsi device probing"? mjg59: "devices handled by the kernel scsi subsystem", which includes SATA ide drives where it probes for devices attached to the controller, as opposed to the controller itself BenC: But by that time it's already registered the i/o ports, surely? mjg59: not always,no loading the controller driver doesn't guarantee anything other than you've opened the controller mjg59: i/o for the controller yes, but for the ports no at that point, you may be lucky enough for the ports to be registered, but not generally device probing on the controller happens later pci_request_regions is done in ata_pci_init_one Which is called directly from the ata_piix PCI probe routine mjg59: there's an easy way to test it btw boot with break=top Keybuk: Well, if I had any SATA machines... modprobe -a piix-sata ide-generic (That is, SATA machines with legacy i/o) about 7/10 times, your drives will be /dev/hda rather than /dev/sda or just trawl malone for the ~100 bugs about that Keybuk: Right, I'm willing to believe that, but I still don't see any mechanism by which this can be true for sata but not for IDE one of them from mdz :) his laptop loves to trigger that case Uh. When did mdz get a new laptop? sorry, strike that; mdz had a different bug, I think Yeah, he had ide-generic binding before piix yeah he doesn't have a sata laptop (Which you've just been telling me is impossible, but :) ) no we loaded ide-generic first in his case that was a clear-out bug :p mjg59: if you start with IDE from the top, you'll see that nothing returns to userspace until the drives are already probed for and bound mjg59: if you start with SCSI/SATA from the top, there are plenty of return to userspace b points before the drives are probed for Keybuk: As far as I can tell, in both the IDE and sata cases, the io regions are requested in the call into the core layer that occurs at the end of the pci probe ok, from what I'm hearing, ide-generic should really be the corner case instead of ide in general I'm not sure about registering of i/o ports, I wasn't looking for that and I don't really understand that Keybuk: It's the registration of i/o ports that's then /entire point/ I was looking at pure "when does the kernel create sdXY and associate it with that driver" If the i/o ports are registered, ide-generic won't bind. Otherwise, it will. but ide-generic does bind Keybuk: Yes, but that's not the problem yeah, which driver grabs the ports from the kernel is the winner So. How can that situation arise in the sata case, but not the ide one? but from what I can tell, there not only i/o per controller, but i/o per device BenC: No One i/o region per channel ok, one per primary and secondary I'm quite happy to change the initramfs code to look like: - load pci drivers - load ide-generic - wait for up to three minutes for the root device to show up - abort Keybuk: Could you take a look at drivers/scsi/ata_piix.c and tell me where it enters userspace between loading and hitting line 4843 of libata-core? I'm genuinely failing to get this I can't see where it gets to libata-core ah, sorry at the bottom right so piix_init calls pci_module_init calls piix_init_one calls ata_pci_init_one Yes Which is identical to the IDE case, as far as I can tell right and is this true for every single sata driver? if it's true that all the sata drivers reserve their regions in init, then I'm happy that may not have been true earlier, or we may have had a different bug ahci seems to do it internally, but doesn't do legacy IDE anyway as far as I can tell and as long as reserving the regions guarantees ide-generic can't steal the devices that still doesn't help out issue where scsi in general is delayed device probing how does it effect that issue? BenC: That's fine. Load all SCSI controllers, loda all PCI IDE, load ide-generic, wait up to three minutes (or whatever) sata behaving like ide doesn't help anything :) this wouldn't distinguish between SCSI and PCI IDE drivers can anyone recall off-hand how we avoid loading both the SATA and PATA driver for a controller? do we do that in the kernel? They have different PCI IDs so basically, from my point of view is, load scsi, ide, ide-generic, loop for 3 minutes checking for device path and/or UUID Scott -- Scott James Remnant scott/ubuntu.com ----- End forwarded message ----- -- ---- WBR, Michael Shigorin ------ Linux.Kiev http://www.linux.kiev.ua/