FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora User

 
 
LinkBack Thread Tools
 
Old 10-10-2011, 10:22 AM
Martin Sivak
 
Default Regarding my recent DD "delay" patch to RHEL6 (#732496)

Hi,

David told me, that some people were curious about why do we need this delay. I will try to explain that.

Currently the sequence in which kernel-udev-anaconda chain works during the loader init in UEFI case:

- kernel detects compiled-in devices
- our init starts
- our init starts udev (and udev doesn't see any new messages - already enumerated devices are not processed)
- init -> loader
- loader calls udev --trigger
- kernel/udev starts enumerating all coldplugged devices + detecting new devices
- usb-storage is detected and starts it's _5_second_ delay (upstream recently changed it to 1 sec and we will change it in 6.2 too)
- loader waits for settled udev (which only means that there are no unprocessed messages in the queue)
- udev settles (usb-storage is still waiting)
- loader enumerates possible DD sources and finds nothing <- this is the bug (DD is not detected in UEFI mode)
- loader commences with normal stuff, net, stage2, ...
- usb-storage ends it's waiting phase and reports all it's drives
- scsi subsystem starts it's 1 second wait to let the drives settle
- udev creates necessary devices
- stage2 is started

Please notice the compiled in delays (total 6 seconds atm.) in kernel modules and the meaning of udev --settle. If kernel takes more time processing something than udev takes processing pending messages, we get the settled state. We depend on it to continue, but it doesn't mean kernel has enumerated all devices. There is no easy way to synchronize this as neither udev nor kernel support any "all done" flag (obviously, how should they now?). Our settle approach works only if there is uninterrupted stream of kernel messages to udev.. and in this case it just isn't true..

Non UEFI worked only because usb-storage was initialized earlier and the delay loops ended earlier than loader entered the enumeration phase.

So the reasoning behind the delays is this. If we add 2 second delay after the first udev trigger, we will match the internal usb/scsi delays and get all the devices. With no driverdiscs, this will cause 2 second delay to the installation. This is the only solution we were able to find with combined effort by me, Harald, Stuart Hayes and Don Zickus (usb-storage guy).

Also I'm not porting this to Fedora, since we plan on killing loader anyways and I will (hopefully) be able to use different approach in dracut environment.

--
Martin Sivák
msivak@redhat.com
Red Hat Czech
Anaconda team / Brno, CZ


_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 

Thread Tools




All times are GMT. The time now is 12:15 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org