----- Original Message ----
> From: Martin Knoblauch <[email protected]>
> To: Rafael J. Wysocki <[email protected]>
> Cc: [email protected]; [email protected]
> Sent: Wednesday, April 22, 2009 6:55:27 PM
> Subject: Re: Booting 2.6.30-rc2-git7 very slow
>
> ----- Original Message ----
>
> > From: Martin Knoblauch
> > To: Rafael J. Wysocki
> > Cc: [email protected]; [email protected]
> > Sent: Wednesday, April 22, 2009 1:32:25 PM
> > Subject: Re: Booting 2.6.30-rc2-git7 very slow
> >
> > ----- Original Message ----
> >
> > > From: Martin Knoblauch
> > > To: Rafael J. Wysocki
> > > Cc: [email protected]
> > > Sent: Wednesday, April 22, 2009 11:56:27 AM
> > > Subject: Re: Booting 2.6.30-rc2-git7 very slow
> > >
> > > > From: Rafael J. Wysocki
> > >
> > > > To: Martin Knoblauch
> > > > Cc: [email protected]
> > > > Sent: Tuesday, April 21, 2009 9:12:20 PM
> > > > Subject: Re: Booting 2.6.30-rc2-git7 very slow
> > > >
> > > > On Tuesday 21 April 2009, Martin Knoblauch wrote:
> > > > >
> > > > > Hi, [please CC me on replies, as I am not subscribed]
> > > > >
> > > > > booting 2.6.30-rc2-git7 on a HP/DL380G3 (x86_64, RHEL4.3, 64 bit
> > > userspace)
> > > > is much slower that it used to be. It seems I run into timeouts when
> [trying
> >
> > > to]
> > > > load intel and tg3 microcodes:
> > > > >
> > > > > [ 14.478892] platform microcode: firmware: requesting
> > intel-ucode/0f-04-0a
> > > > > [ 74.476741] platform microcode: firmware: requesting
> > intel-ucode/0f-04-0a
> > > > > [ 134.476638] platform microcode: firmware: requesting
> > intel-ucode/0f-04-0a
> > > > > [ 194.476637] platform microcode: firmware: requesting
> > intel-ucode/0f-04-0a
> > > > > [ 254.476493] Microcode Update Driver: v2.00 ,
> > > > Peter Oruba
> > > > > [ 254.718489] Microcode Update Driver: v2.00 removed.
> > > > >
> > > > > So, we see 60 seconds for eaoch of the CPUs
> > > > >
> > > > > [ 255.273426] tg3 0000:03:01.0: PME# disabled
> > > > > [ 257.833769] tg3: eth0: Link is up at 1000 Mbps, full duplex.
> > > > > [ 257.833775] tg3: eth0: Flow control is off for TX and off for RX.
> > > > > [ 269.643973] tg3 0000:03:01.1: firmware: requesting tigon/tg3_tso.bin
> > > > > [ 329.640456] eth1: Failed to load firmware "tigon/tg3_tso.bin"
> > > > > [ 329.640463] eth1: TSO capability disabled.
> > > > > [ 329.640487] tg3 0000:03:01.1: PME# disabled
> > > > > [ 333.081753] tg3: eth1: Link is up at 1000 Mbps, full duplex.
> > > > > [ 333.081759] tg3: eth1: Flow control is off for TX and off for RX.
> > > > >
> > > > > We see 60 seconds for eth1, complaining about a failed firmware load.
> > > > > /lib/firmware/tigon/tg3_tso.bin does exist and is from the current
> > > > > build.
> > > >
> > > > Do I assume correctly that 2.6.29 did not have this problem?
> > > >
> > >
> > > Just checked. 2.6.29 has exactely the same problem. 2.6.28.2 was OK. This is
>
> > > from the 2.6.29 boot:
> > >
> > > [ 14.308340] platform microcode: firmware: requesting intel-ucode/0f-04-0a
> > > [ 74.304612] platform microcode: firmware: requesting intel-ucode/0f-04-0a
> > > [ 134.304651] platform microcode: firmware: requesting intel-ucode/0f-04-0a
> > > [ 194.304638] platform microcode: firmware: requesting intel-ucode/0f-04-0a
> > > [ 254.304597] Microcode Update Driver: v2.00 , Peter Oruba
> > > [ 254.546200] Microcode Update Driver: v2.00 removed.
> >
> > In case of the platform microcode, the delays happen when doing:
> >
> > /sbin/modprobe microcode
> >
> > from the init script. I have a "microcode.dat" File in both /etc/ and
> > /etc/firmware.
> >
> > > [ 255.088405] tg3 0000:03:01.0: PME# disabled
> > > [ 257.669617] tg3: eth0: Link is up at 1000 Mbps, full duplex.
> > > [ 257.669622] tg3: eth0: Flow control is off for TX and off for RX.
> > > [ 269.456132] tg3 0000:03:01.1: firmware: requesting tigon/tg3_tso.bin
> > > [ 329.456495] eth1: Failed to load firmware "tigon/tg3_tso.bin"
> > > [ 329.456500] eth1: TSO capability disabled.
> > > [ 329.456524] tg3 0000:03:01.1: PME# disabled
> > > [ 332.921832] tg3: eth1: Link is up at 1000 Mbps, full duplex.
> > > [ 332.921837] tg3: eth1: Flow control is off for TX and off for RX.
> > >
> > >
> >
>
> OK, I was able to solve the tg3 failure by adding "tigon/tg3_tso.bin" to
> CONFIG_EXTRA_FIRMWARE. I tried the same with the CPU microcode (after copying
> /etc/firmware/microcode.dat to $BUILDDIR/firmware/), but no success.
>
> Searching the archives also found some mentioning that I might need special
> udev-rules to make firmware loading work again transparently. But no explicit
> solution.
>
> I find this new (since 2.6.29) behaviour:
>
> - very unexpected
> - not well documented
> - the EXTRA_FIRMWARE solution very unscalable
>
OK, I just found the reason for both intel-ucode and tg3 failures. Apparently between 2.6.28 and 2.6.29 the mount of sysfs has subtely changed from:
/sys /sys sysfs rw 0 0
to:
none /sys sysfs rw,relatime 0 0
The "none" breaks the RHEL-4 provided hotplug script "firmware.agent" when it tries to parse the mount point for "/sys". As a result, the firmware loading is never properly finished and the driver(s) just timeout on the value in /sys/class/firmware/timeout. Bingo. Simple fix in user-pace possible - cool down Martin :-)
Questions remains: was this intentional? It breaks existing userspace and should therefore be considered a regression - right? On the other hand, it will never be a problem for RHEL-4/5 kernels, unless the change in 2.6.29 gets backported. Any ideas?
Cheers
Martin
On Fri, 24 Apr 2009 05:45:19 -0700 (PDT) Martin Knoblauch <[email protected]> wrote:
>
>
> OK, I just found the reason for both intel-ucode and tg3 failures. Apparently between 2.6.28 and 2.6.29 the mount of sysfs has subtely changed from:
>
> /sys /sys sysfs rw 0 0
>
> to:
>
> none /sys sysfs rw,relatime 0 0
I assume that you're referring to the contents of /proc/mounts?
> The "none" breaks the RHEL-4 provided hotplug script "firmware.agent" when it tries to parse the mount point for "/sys". As a result, the firmware loading is never properly finished and the driver(s) just timeout on the value in /sys/class/firmware/timeout. Bingo. Simple fix in user-pace possible - cool down Martin :-)
>
> Questions remains: was this intentional? It breaks existing userspace and should therefore be considered a regression - right? On the other hand, it will never be a problem for RHEL-4/5 kernels, unless the change in 2.6.29 gets backported. Any ideas?
afaik that was unintentional and was probably a mistake.
I wonder how we did that.
On Tue, 2009-04-28 at 18:28 -0700, Andrew Morton wrote:
> On Fri, 24 Apr 2009 05:45:19 -0700 (PDT) Martin Knoblauch <[email protected]> wrote:
>
> >
> >
> > OK, I just found the reason for both intel-ucode and tg3 failures. Apparently between 2.6.28 and 2.6.29 the mount of sysfs has subtely changed from:
> >
> > /sys /sys sysfs rw 0 0
> >
> > to:
> >
> > none /sys sysfs rw,relatime 0 0
>
> I assume that you're referring to the contents of /proc/mounts?
>
> > The "none" breaks the RHEL-4 provided hotplug script "firmware.agent" when it tries to parse the mount point for "/sys". As a result, the firmware loading is never properly finished and the driver(s) just timeout on the value in /sys/class/firmware/timeout. Bingo. Simple fix in user-pace possible - cool down Martin :-)
> >
> > Questions remains: was this intentional? It breaks existing userspace and should therefore be considered a regression - right? On the other hand, it will never be a problem for RHEL-4/5 kernels, unless the change in 2.6.29 gets backported. Any ideas?
>
> afaik that was unintentional and was probably a mistake.
>
> I wonder how we did that.
<paste>
> [hotplug]# grep sysfs /proc/mounts
> none /sys sysfs rw,relatime 0 0
> /sys /sys sysfs rw,relatime 0 0
(I wonder how the heck that is accomplished)
On Wed, 29 Apr 2009 05:51:36 +0200 Mike Galbraith <[email protected]> wrote:
> On Tue, 2009-04-28 at 18:28 -0700, Andrew Morton wrote:
> > On Fri, 24 Apr 2009 05:45:19 -0700 (PDT) Martin Knoblauch <[email protected]> wrote:
> >
> > >
> > >
> > > OK, I just found the reason for both intel-ucode and tg3 failures. Apparently between 2.6.28 and 2.6.29 the mount of sysfs has subtely changed from:
> > >
> > > /sys /sys sysfs rw 0 0
> > >
> > > to:
> > >
> > > none /sys sysfs rw,relatime 0 0
> >
> > I assume that you're referring to the contents of /proc/mounts?
> >
> > > The "none" breaks the RHEL-4 provided hotplug script "firmware.agent" when it tries to parse the mount point for "/sys". As a result, the firmware loading is never properly finished and the driver(s) just timeout on the value in /sys/class/firmware/timeout. Bingo. Simple fix in user-pace possible - cool down Martin :-)
> > >
> > > Questions remains: was this intentional? It breaks existing userspace and should therefore be considered a regression - right? On the other hand, it will never be a problem for RHEL-4/5 kernels, unless the change in 2.6.29 gets backported. Any ideas?
> >
> > afaik that was unintentional and was probably a mistake.
> >
> > I wonder how we did that.
>
> <paste>
> > [hotplug]# grep sysfs /proc/mounts
> > none /sys sysfs rw,relatime 0 0
> > /sys /sys sysfs rw,relatime 0 0
>
> ___(I wonder how the heck that is accomplished)
>
Beats me. I'm not seeing likely changes in fs/proc/base.c or around
show_mountinfo(). Maybe sysfs broke in an ingenious way. (hopefully
cc's viro).
Displaying relatime seems a bit pointless too.
----- Original Message ----
> From: Andrew Morton <[email protected]>
> To: Martin Knoblauch <[email protected]>
> Cc: Rafael J. Wysocki <[email protected]>; [email protected]; [email protected]; tigran aivazian <[email protected]>
> Sent: Wednesday, April 29, 2009 3:28:37 AM
> Subject: Re: Analyzed/Solved: Booting 2.6.30-rc2-git7 very slow
>
> On Fri, 24 Apr 2009 05:45:19 -0700 (PDT) Martin Knoblauch
> wrote:
>
> >
> >
> > OK, I just found the reason for both intel-ucode and tg3 failures. Apparently
> between 2.6.28 and 2.6.29 the mount of sysfs has subtely changed from:
> >
> > /sys /sys sysfs rw 0 0
> >
> > to:
> >
> > none /sys sysfs rw,relatime 0 0
>
> I assume that you're referring to the contents of /proc/mounts?
>
> > The "none" breaks the RHEL-4 provided hotplug script "firmware.agent" when it
> tries to parse the mount point for "/sys". As a result, the firmware loading is
> never properly finished and the driver(s) just timeout on the value in
> /sys/class/firmware/timeout. Bingo. Simple fix in user-pace possible - cool down
> Martin :-)
> >
> > Questions remains: was this intentional? It breaks existing userspace and
> should therefore be considered a regression - right? On the other hand, it will
> never be a problem for RHEL-4/5 kernels, unless the change in 2.6.29 gets
> backported. Any ideas?
>
> afaik that was unintentional and was probably a mistake.
>
> I wonder how we did that.
Actually, what breaks the RHEL-4.3 script is not the "none", but the duplicate lines in /proc/mounts that I reported earlier in the "regression" thread.
[root@lpsdm52]# grep sysfs /proc/mounts
none /sys sysfs rw,relatime 0 0
/sys /sys sysfs rw,relatime 0 0
One of them likely comes from the respective line in /etc/fstab, but where does the second one come from?
Cheers
Martin
------------------------------------------------------
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www: http://www.knobisoft.de
----- Original Message ----
> From: Andrew Morton <[email protected]>
> To: Mike Galbraith <[email protected]>
> Cc: Martin Knoblauch <[email protected]>; Rafael J. Wysocki <[email protected]>; [email protected]; tigran aivazian <[email protected]>; Al Viro <[email protected]>
> Sent: Wednesday, April 29, 2009 10:17:55 AM
> Subject: Re: Analyzed/Solved: Booting 2.6.30-rc2-git7 very slow
>
> On Wed, 29 Apr 2009 05:51:36 +0200 Mike Galbraith wrote:
>
> > On Tue, 2009-04-28 at 18:28 -0700, Andrew Morton wrote:
> > > On Fri, 24 Apr 2009 05:45:19 -0700 (PDT) Martin Knoblauch
> wrote:
> > >
> > > >
> > > >
> > > > OK, I just found the reason for both intel-ucode and tg3 failures.
> Apparently between 2.6.28 and 2.6.29 the mount of sysfs has subtely changed
> from:
> > > >
> > > > /sys /sys sysfs rw 0 0
> > > >
> > > > to:
> > > >
> > > > none /sys sysfs rw,relatime 0 0
> > >
> > > I assume that you're referring to the contents of /proc/mounts?
> > >
> > > > The "none" breaks the RHEL-4 provided hotplug script "firmware.agent"
> when it tries to parse the mount point for "/sys". As a result, the firmware
> loading is never properly finished and the driver(s) just timeout on the value
> in /sys/class/firmware/timeout. Bingo. Simple fix in user-pace possible - cool
> down Martin :-)
> > > >
> > > > Questions remains: was this intentional? It breaks existing userspace and
> should therefore be considered a regression - right? On the other hand, it will
> never be a problem for RHEL-4/5 kernels, unless the change in 2.6.29 gets
> backported. Any ideas?
> > >
> > > afaik that was unintentional and was probably a mistake.
> > >
> > > I wonder how we did that.
> >
> >
> > > [hotplug]# grep sysfs /proc/mounts
> > > none /sys sysfs rw,relatime 0 0
> > > /sys /sys sysfs rw,relatime 0 0
> >
> > ___(I wonder how the heck that is accomplished)
> >
>
> Beats me. I'm not seeing likely changes in fs/proc/base.c or around
> show_mountinfo(). Maybe sysfs broke in an ingenious way. (hopefully
> cc's viro).
>
> Displaying relatime seems a bit pointless too.
Actually, relatime is added in 2.6.30. In 2.6.29 I only see the duplicate lines.
Cheers
Martin
----- Original Message ----
> From: Andrew Morton <[email protected]>
> To: Mike Galbraith <[email protected]>
> Cc: Martin Knoblauch <[email protected]>; Rafael J. Wysocki <[email protected]>; [email protected]; tigran aivazian <[email protected]>; Al Viro <[email protected]>
> Sent: Wednesday, April 29, 2009 10:17:55 AM
> Subject: Re: Analyzed/Solved: Booting 2.6.30-rc2-git7 very slow
>
> On Wed, 29 Apr 2009 05:51:36 +0200 Mike Galbraith wrote:
>
> > On Tue, 2009-04-28 at 18:28 -0700, Andrew Morton wrote:
> > > On Fri, 24 Apr 2009 05:45:19 -0700 (PDT) Martin Knoblauch
> wrote:
> > >
> > > >
> > > >
> > > > OK, I just found the reason for both intel-ucode and tg3 failures.
> Apparently between 2.6.28 and 2.6.29 the mount of sysfs has subtely changed
> from:
> > > >
> > > > /sys /sys sysfs rw 0 0
> > > >
> > > > to:
> > > >
> > > > none /sys sysfs rw,relatime 0 0
> > >
> > > I assume that you're referring to the contents of /proc/mounts?
> > >
> > > > The "none" breaks the RHEL-4 provided hotplug script "firmware.agent"
> when it tries to parse the mount point for "/sys". As a result, the firmware
> loading is never properly finished and the driver(s) just timeout on the value
> in /sys/class/firmware/timeout. Bingo. Simple fix in user-pace possible - cool
> down Martin :-)
> > > >
> > > > Questions remains: was this intentional? It breaks existing userspace and
> should therefore be considered a regression - right? On the other hand, it will
> never be a problem for RHEL-4/5 kernels, unless the change in 2.6.29 gets
> backported. Any ideas?
> > >
> > > afaik that was unintentional and was probably a mistake.
> > >
> > > I wonder how we did that.
> >
> >
> > > [hotplug]# grep sysfs /proc/mounts
> > > none /sys sysfs rw,relatime 0 0
> > > /sys /sys sysfs rw,relatime 0 0
> >
> > ___(I wonder how the heck that is accomplished)
> >
>
> Beats me. I'm not seeing likely changes in fs/proc/base.c or around
> show_mountinfo(). Maybe sysfs broke in an ingenious way. (hopefully
> cc's viro).
>
> Displaying relatime seems a bit pointless too.
Hmm. I actually believe the "none" line comes out of /etc/fstab, but was never before displayed in /proc/mount.
This is from 2.6.19:
[root@lpsdm60 ~]# grep sysfs /etc/fstab
none /sys sysfs defaults 0 0
[root@lpsdm60 ~]# mount | grep sysfs
none on /sys type sysfs (rw)
[root@lpsdm60 ~]# grep sysfs /proc/mounts
/sys /sys sysfs rw 0 0
And this is from 2.6.30:
[root@lpsdm52 linux-2.6.30-rc3-git2]# grep sysfs /etc/fstab
none /sys sysfs defaults 0 0
[root@lpsdm52 linux-2.6.30-rc3-git2]# mount | grep sysfs
none on /sys type sysfs (rw)
[root@lpsdm52 linux-2.6.30-rc3-git2]# grep sysfs /proc/mounts
none /sys sysfs rw,relatime 0 0
/sys /sys sysfs rw,relatime 0 0
Any changes to mount-handling in 2.6.29?
Cheers
Martin
On Wed, Apr 29, 2009 at 01:17:55AM -0700, Andrew Morton wrote:
> > > > Questions remains: was this intentional? It breaks existing userspace and should therefore be considered a regression - right? On the other hand, it will never be a problem for RHEL-4/5 kernels, unless the change in 2.6.29 gets backported. Any ideas?
> > >
> > > afaik that was unintentional and was probably a mistake.
> > >
> > > I wonder how we did that.
> >
> > <paste>
> > > [hotplug]# grep sysfs /proc/mounts
> > > none /sys sysfs rw,relatime 0 0
> > > /sys /sys sysfs rw,relatime 0 0
> >
> > ___(I wonder how the heck that is accomplished)
>
> Beats me. I'm not seeing likely changes in fs/proc/base.c or around
> show_mountinfo(). Maybe sysfs broke in an ingenious way. (hopefully
> cc's viro).
Er... Somebody mounting sysfs twice? From some init script and from
/etc/fstab, perhaps? That definitely looks like two mount(2) had to
have been done to cause that...
On Wed, 2009-04-29 at 13:08 +0100, Al Viro wrote:
> On Wed, Apr 29, 2009 at 01:17:55AM -0700, Andrew Morton wrote:
>
> > > > > Questions remains: was this intentional? It breaks existing userspace and should therefore be considered a regression - right? On the other hand, it will never be a problem for RHEL-4/5 kernels, unless the change in 2.6.29 gets backported. Any ideas?
> > > >
> > > > afaik that was unintentional and was probably a mistake.
> > > >
> > > > I wonder how we did that.
> > >
> > > <paste>
> > > > [hotplug]# grep sysfs /proc/mounts
> > > > none /sys sysfs rw,relatime 0 0
> > > > /sys /sys sysfs rw,relatime 0 0
> > >
> > > ___(I wonder how the heck that is accomplished)
> >
> > Beats me. I'm not seeing likely changes in fs/proc/base.c or around
> > show_mountinfo(). Maybe sysfs broke in an ingenious way. (hopefully
> > cc's viro).
>
> Er... Somebody mounting sysfs twice? From some init script and from
> /etc/fstab, perhaps? That definitely looks like two mount(2) had to
> have been done to cause that...
Yeah, but how does one go about doing that?
Using mount -f, I can convince mount to succeed, but I still have only
one entry in /proc/mounts, despite what my mount binary imagines.
marge:..sys/vm # grep sysfs /proc/mounts
sysfs /sys sysfs rw,relatime 0 0
marge:..sys/vm # mount|grep sysfs
sysfs on /sys type sysfs (rw)
sys on /sys type sysfs (rw)
/sys on /sys type sysfs (rw)
-Mike
On Wed, Apr 29, 2009 at 04:18:45PM +0200, Mike Galbraith wrote:
> > /etc/fstab, perhaps? That definitely looks like two mount(2) had to
> > have been done to cause that...
>
> Yeah, but how does one go about doing that?
>
> Using mount -f, I can convince mount to succeed, but I still have only
> one entry in /proc/mounts, despite what my mount binary imagines.
Huh?
-f Causes everything to be done except for the actual system call;
if it's not obvious, this ``fakes'' mounting the file system.
This option is useful in conjunction with the -v flag to deter-
mine what the mount command is trying to do. It can also be used
to add entries for devices that were mounted earlier with the -n
What are you talking about?
The interesting part is why mount(2) doesn't fail with -EBUSY on that
overmounting. Is there anything else mounted on /sys? That, or any
interesting patches applied to the tree (fs/sysfs/mount.c, fs/namespace.c)
----- Original Message ----
> From: Al Viro <[email protected]>
> To: Andrew Morton <[email protected]>
> Cc: Mike Galbraith <[email protected]>; Martin Knoblauch <[email protected]>; Rafael J. Wysocki <[email protected]>; [email protected]; tigran aivazian <[email protected]>
> Sent: Wednesday, April 29, 2009 2:08:28 PM
> Subject: Re: Analyzed/Solved: Booting 2.6.30-rc2-git7 very slow
>
> On Wed, Apr 29, 2009 at 01:17:55AM -0700, Andrew Morton wrote:
>
> > > > > Questions remains: was this intentional? It breaks existing userspace
> and should therefore be considered a regression - right? On the other hand, it
> will never be a problem for RHEL-4/5 kernels, unless the change in 2.6.29 gets
> backported. Any ideas?
> > > >
> > > > afaik that was unintentional and was probably a mistake.
> > > >
> > > > I wonder how we did that.
> > >
> > >
> > > > [hotplug]# grep sysfs /proc/mounts
> > > > none /sys sysfs rw,relatime 0 0
> > > > /sys /sys sysfs rw,relatime 0 0
> > >
> > > ___(I wonder how the heck that is accomplished)
> >
> > Beats me. I'm not seeing likely changes in fs/proc/base.c or around
> > show_mountinfo(). Maybe sysfs broke in an ingenious way. (hopefully
> > cc's viro).
>
> Er... Somebody mounting sysfs twice? From some init script and from
> /etc/fstab, perhaps? That definitely looks like two mount(2) had to
> have been done to cause that...
One definitely comes from /etc/fstab, but I am not aware of any other script mounting sysfs in my userspace.
Cheers
Martin
----- Original Message ----
> From: Al Viro <[email protected]>
> To: Mike Galbraith <[email protected]>
> Cc: Andrew Morton <[email protected]>; Martin Knoblauch <[email protected]>; Rafael J. Wysocki <[email protected]>; [email protected]; tigran aivazian <[email protected]>
> Sent: Wednesday, April 29, 2009 4:34:03 PM
> Subject: Re: Analyzed/Solved: Booting 2.6.30-rc2-git7 very slow
>
> On Wed, Apr 29, 2009 at 04:18:45PM +0200, Mike Galbraith wrote:
> > > /etc/fstab, perhaps? That definitely looks like two mount(2) had to
> > > have been done to cause that...
> >
> > Yeah, but how does one go about doing that?
> >
> > Using mount -f, I can convince mount to succeed, but I still have only
> > one entry in /proc/mounts, despite what my mount binary imagines.
>
> Huh?
> -f Causes everything to be done except for the actual system call;
> if it's not obvious, this ``fakes'' mounting the file system.
> This option is useful in conjunction with the -v flag to deter-
> mine what the mount command is trying to do. It can also be used
> to add entries for devices that were mounted earlier with the -n
>
> What are you talking about?
>
> The interesting part is why mount(2) doesn't fail with -EBUSY on that
> overmounting. Is there anything else mounted on /sys? That, or any
> interesting patches applied to the tree (fs/sysfs/mount.c, fs/namespace.c)
In my 2.6.30-rc3-git2 there is definitely nothing interesting, just my NFS readahead patch. But that touches nothing near sysfs. And my 2.6.29 test-boot was from a plain build.
Cheers
Martin
On Wed, 29 Apr 2009 10:24:20 PDT, Martin Knoblauch said:
> One definitely comes from /etc/fstab, but I am not aware of any other script
mounting sysfs in my userspace.
You said it was a RedHat box?
Look in /etc/rc.sysinit:
mount -n -t sysfs /sys /sys >/dev/null 2>&1
(Near line 28 for RHEL 4, line 23 for RHEL5, and line 21 for Fedora Rawhide)
Probably your culprit.
On Wed, Apr 29, 2009 at 10:24:20AM -0700, Martin Knoblauch wrote:
> > Er... Somebody mounting sysfs twice? From some init script and from
> > /etc/fstab, perhaps? That definitely looks like two mount(2) had to
> > have been done to cause that...
>
> One definitely comes from /etc/fstab, but I am not aware of any other script mounting sysfs in my userspace.
Check in /etc/init.d; e.g. on debian it's mountkernfs. More interesting
question is what else is mounted on /sys; how about the entire /proc/mounts
contents?
On Wed, Apr 29, 2009 at 01:35:59PM -0400, [email protected] wrote:
> On Wed, 29 Apr 2009 10:24:20 PDT, Martin Knoblauch said:
>
> > One definitely comes from /etc/fstab, but I am not aware of any other script
> mounting sysfs in my userspace.
>
> You said it was a RedHat box?
>
> Look in /etc/rc.sysinit:
>
> mount -n -t sysfs /sys /sys >/dev/null 2>&1
>
> (Near line 28 for RHEL 4, line 23 for RHEL5, and line 21 for Fedora Rawhide)
>
> Probably your culprit.
Again, the interesting question is WTF had mount(2) not failed with -EBUSY
----- Original Message ----
> From: "[email protected]" <[email protected]>
> To: Martin Knoblauch <[email protected]>
> Cc: Al Viro <[email protected]>; Andrew Morton <[email protected]>; Mike Galbraith <[email protected]>; Rafael J. Wysocki <[email protected]>; [email protected]; tigran aivazian <[email protected]>
> Sent: Wednesday, April 29, 2009 7:35:59 PM
> Subject: Re: Analyzed/Solved: Booting 2.6.30-rc2-git7 very slow
>
> On Wed, 29 Apr 2009 10:24:20 PDT, Martin Knoblauch said:
>
> > One definitely comes from /etc/fstab, but I am not aware of any other script
> mounting sysfs in my userspace.
>
> You said it was a RedHat box?
>
> Look in /etc/rc.sysinit:
>
> mount -n -t sysfs /sys /sys >/dev/null 2>&1
>
> (Near line 28 for RHEL 4, line 23 for RHEL5, and line 21 for Fedora Rawhide)
>
> Probably your culprit.
OK, you got me. But still something changed with 2.6.29. Before, there was only one line in /proc/mounts
Cheers
Martin
------------------------------------------------------
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www: http://www.knobisoft.de
----- Original Message ----
> From: Al Viro <[email protected]>
> To: Martin Knoblauch <[email protected]>
> Cc: Andrew Morton <[email protected]>; Mike Galbraith <[email protected]>; Rafael J. Wysocki <[email protected]>; [email protected]; tigran aivazian <[email protected]>
> Sent: Wednesday, April 29, 2009 7:41:54 PM
> Subject: Re: Analyzed/Solved: Booting 2.6.30-rc2-git7 very slow
>
> On Wed, Apr 29, 2009 at 10:24:20AM -0700, Martin Knoblauch wrote:
>
> > > Er... Somebody mounting sysfs twice? From some init script and from
> > > /etc/fstab, perhaps? That definitely looks like two mount(2) had to
> > > have been done to cause that...
> >
> > One definitely comes from /etc/fstab, but I am not aware of any other script
> mounting sysfs in my userspace.
>
> Check in /etc/init.d; e.g. on debian it's mountkernfs. More interesting
> question is what else is mounted on /sys; how about the entire /proc/mounts
> contents?
2.6.30-rc3-git2:
rootfs / rootfs rw 0 0
/proc /proc proc rw,relatime 0 0
none /sys sysfs rw,relatime 0 0
none /dev tmpfs rw,relatime,mode=755 0 0
/dev/root / ext3 rw,relatime,errors=continue,data=writeback 0 0
none /dev tmpfs rw,relatime,mode=755 0 0
/proc /proc proc rw,relatime 0 0
/proc/bus/usb /proc/bus/usb usbfs rw,relatime 0 0
/sys /sys sysfs rw,relatime 0 0
none /dev/pts devpts rw,relatime,gid=5,mode=620 0 0
/dev/cciss/c0d0p1 /boot ext3 rw,relatime,errors=continue,data=writeback 0 0
none /dev/shm tmpfs rw,relatime 0 0
/dev/cciss/c0d0p4 /scratch ext2 rw,noatime,errors=continue 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0
2.6.19.2
rootfs / rootfs rw 0 0
/proc /proc proc rw 0 0
none /dev tmpfs rw 0 0
/dev/root / ext3 rw,data=ordered 0 0
none /dev tmpfs rw 0 0
/proc /proc proc rw 0 0
/proc/bus/usb /proc/bus/usb usbfs rw 0 0
/sys /sys sysfs rw 0 0
none /dev/pts devpts rw 0 0
/dev/cciss/c0d0p1 /boot ext3 rw,data=ordered 0 0
none /dev/shm tmpfs rw 0 0
/dev/VolGroup00/LogVol02 /scratch ext2 rw,noatime 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0
Cheers
Martin
On Wed, Apr 29, 2009 at 10:51:35AM -0700, Martin Knoblauch wrote:
> 2.6.30-rc3-git2:
>
> rootfs / rootfs rw 0 0
> /proc /proc proc rw,relatime 0 0
> none /sys sysfs rw,relatime 0 0
> none /dev tmpfs rw,relatime,mode=755 0 0
> /dev/root / ext3 rw,relatime,errors=continue,data=writeback 0 0
> none /dev tmpfs rw,relatime,mode=755 0 0
> /proc /proc proc rw,relatime 0 0
> /proc/bus/usb /proc/bus/usb usbfs rw,relatime 0 0
> /sys /sys sysfs rw,relatime 0 0
> none /dev/pts devpts rw,relatime,gid=5,mode=620 0 0
> /dev/cciss/c0d0p1 /boot ext3 rw,relatime,errors=continue,data=writeback 0 0
> none /dev/shm tmpfs rw,relatime 0 0
> /dev/cciss/c0d0p4 /scratch ext2 rw,noatime,errors=continue 0 0
> none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
> sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0
Cute... I wonder how that second mount(2) managed to succeed. Could you
check what explicit mounting of sysfs on that point *again* does?
On Wed, 2009-04-29 at 15:34 +0100, Al Viro wrote:
> On Wed, Apr 29, 2009 at 04:18:45PM +0200, Mike Galbraith wrote:
> > > /etc/fstab, perhaps? That definitely looks like two mount(2) had to
> > > have been done to cause that...
> >
> > Yeah, but how does one go about doing that?
> >
> > Using mount -f, I can convince mount to succeed, but I still have only
> > one entry in /proc/mounts, despite what my mount binary imagines.
>
> Huh?
> -f Causes everything to be done except for the actual system call;
> if it's not obvious, this ``fakes'' mounting the file system.
> This option is useful in conjunction with the -v flag to deter-
> mine what the mount command is trying to do. It can also be used
> to add entries for devices that were mounted earlier with the -n
>
> What are you talking about?
Me? My binary lost touch with reality, but I couldn't induce it to
produce two /proc/mount entries. I thought that's what I said.
-Mike
----- Original Message ----
> From: Al Viro <[email protected]>
> To: Martin Knoblauch <[email protected]>
> Cc: Andrew Morton <[email protected]>; Mike Galbraith <[email protected]>; Rafael J. Wysocki <[email protected]>; [email protected]; tigran aivazian <[email protected]>
> Sent: Wednesday, April 29, 2009 8:10:41 PM
> Subject: Re: Analyzed/Solved: Booting 2.6.30-rc2-git7 very slow
>
> On Wed, Apr 29, 2009 at 10:51:35AM -0700, Martin Knoblauch wrote:
> > 2.6.30-rc3-git2:
> >
> > rootfs / rootfs rw 0 0
> > /proc /proc proc rw,relatime 0 0
> > none /sys sysfs rw,relatime 0 0
> > none /dev tmpfs rw,relatime,mode=755 0 0
> > /dev/root / ext3 rw,relatime,errors=continue,data=writeback 0 0
> > none /dev tmpfs rw,relatime,mode=755 0 0
> > /proc /proc proc rw,relatime 0 0
> > /proc/bus/usb /proc/bus/usb usbfs rw,relatime 0 0
> > /sys /sys sysfs rw,relatime 0 0
> > none /dev/pts devpts rw,relatime,gid=5,mode=620 0 0
> > /dev/cciss/c0d0p1 /boot ext3 rw,relatime,errors=continue,data=writeback 0 0
> > none /dev/shm tmpfs rw,relatime 0 0
> > /dev/cciss/c0d0p4 /scratch ext2 rw,noatime,errors=continue 0 0
> > none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
> > sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0
>
> Cute... I wonder how that second mount(2) managed to succeed. Could you
> check what explicit mounting of sysfs on that point *again* does?
Hi Al,
by now I know a bit more. Starting with 2.6.29, the
none /sys sysfs rw 0 0
line is already in /proc/mounts when entering userspace. So I guess it comes out of my initrd. Again, what changed?
Cheers
Martin
On Wed, Apr 29, 2009 at 06:43:23PM +0100, Al Viro wrote:
> Again, the interesting question is WTF had mount(2) not failed with -EBUSY
A change of '/' between the two mounts maybe? If one is done from
initrd and the other after / is mounted?
OG.