public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Jon Smirl <jonsmirl@gmail.com>,
	linux-kernel@vger.kernel.org, Jens Axboe <axboe@suse.de>
Subject: Re: current linus bk, error mounting root
Date: Mon, 21 Mar 2005 16:38:08 -0800	[thread overview]
Message-ID: <20050322003807.GA10180@kroah.com> (raw)
In-Reply-To: <20050321161925.76c37a7f.akpm@osdl.org>

On Mon, Mar 21, 2005 at 04:19:25PM -0800, Andrew Morton wrote:
> 
> (Adds lots of cc's.  I trust that's OK).
> 
> Jon Smirl <jonsmirl@gmail.com> wrote:
> >
> > No, I think Jens wants all of the distributions to fix it. I have
> > filed a bug with Fedora on it.
> > 
> > Something changed in the timing for loading drivers during boot. You
> > used to be able to do:
> > modprobe ata_piix
> > mount /dev/sda1

You can't do that on any udev based system reliably.  That has _never_
been true.  You might just have been getting lucky in the past.

> > Now you have to do this:
> > modprobe ata_piix
> > sleep 1
> > mount /dev/sda1

That's still racy.  Rely on the /etc/dev.d/ notifier to be able to tell
you when you can mount your device, that is what it is there for.

This is a udev issue, not a kernel issue, there's nothing we can do in
the kernel about it (well, except for the obvious thing of giving udev
lots of hints and making it easier for it to work properly and faster,
which we have been doing over the past months.)

> > I suspect the problem is that udev doesn't get a chance to run anymore. 
> > The sleep 1 allows it to run and it creates /dev/sda1.
> > Build ata_piix in and the problem goes away too.
> > 
> > Jens is right that this is a user space issue, but how many people are
> > going to find this out the hard way when their root drives stop
> > mounting. Since no one is complaining I have to assume that most
> > kernel developers have their root device drivers built into the
> > kernel. I was loading mine as a module since for a long time Redhat
> > was not shipping kernels with SATA built in.
> 
> I don't agree that this is a userspace issue.  It's just not sane for a
> driver to be in an unusable state for an arbitrary length of time after
> modprobe returns.

It is a userspace issue.  If you have a static /dev there are no
problems, right?  If you use udev, you need to wait for the device node
to show up, it will not be there right after modprobe returns.

thanks,

greg k-h

  reply	other threads:[~2005-03-22  0:40 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-09 17:03 current linus bk, error mounting root Jon Smirl
2005-03-09 17:16 ` Jeff Garzik
2005-03-09 18:23   ` Jon Smirl
2005-03-09 20:28     ` Jeff Garzik
2005-03-09 20:31     ` Jeff Garzik
2005-03-09 20:51       ` Jon Smirl
2005-03-09 21:09         ` Jens Axboe
2005-03-10  1:16           ` Jon Smirl
2005-03-10  7:50             ` Jens Axboe
2005-03-10 14:58               ` Jon Smirl
2005-03-10 15:31                 ` Jens Axboe
2005-03-10 15:45                   ` Jon Smirl
2005-03-10 15:48                     ` Jens Axboe
2005-03-10 15:59                       ` Jon Smirl
2005-03-10 16:01                         ` Jens Axboe
2005-03-10 16:18                           ` Jon Smirl
2005-03-10 16:29                             ` Jens Axboe
2005-03-10 18:40                               ` Jon Smirl
2005-03-10 18:52                               ` Jon Smirl
2005-03-11  3:11                                 ` Matt Mackall
2005-03-11  3:18                                   ` Jon Smirl
2005-03-15 15:39                               ` Jon Smirl
2005-03-15 15:47                                 ` Jens Axboe
2005-03-09 20:34     ` Steven Cole
     [not found] ` <20050321154131.30616ed0.akpm@osdl.org>
     [not found]   ` <9e473391050321155735fc506d@mail.gmail.com>
2005-03-22  0:19     ` Andrew Morton
2005-03-22  0:38       ` Greg KH [this message]
2005-03-22  0:43         ` Andrew Morton
2005-03-22  0:49           ` Greg KH
2005-03-22  0:57             ` Jon Smirl
2005-03-22  4:02               ` Greg KH
2005-03-22  1:13             ` Jon Smirl
2005-03-22  0:53           ` Jon Smirl
2005-03-22  4:03             ` Greg KH
2005-03-22  0:47         ` Jon Smirl
2005-03-22  1:14       ` Kyle Moffett
2005-03-22  4:02         ` Greg KH
  -- strict thread matches above, loose matches on Subject: below --
2005-03-12 13:15 Alexander E. Patrakov
2005-03-12 19:56 ` Jon Smirl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050322003807.GA10180@kroah.com \
    --to=greg@kroah.com \
    --cc=akpm@osdl.org \
    --cc=axboe@suse.de \
    --cc=jonsmirl@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox