Re: Linux 2.6.35

Re: Linux 2.6.35

[Donald Parsons]

2.6.35 still fails to boot for me, as first reported here:
 http://lkml.indiana.edu/hypermail/linux/kernel/1007.3/01144.html

I've manually bisected it down to around May 20 between
  2.6.34-git4 (boots) and 2.6.34-git5 (boot fails)
Also -git[23] boot, and -git8, -rc[126], rc6-git[136] all fail.

Unfortunately first time I tried was with 2.6.35-rc6 and
it failed to boot.

Failure when switching from initramfs to real /root?
Removing kernel "quiet" param appears to show several
lines listing:

  usb drives/hubs? followed by
  dracut switching root (when booting works)
              or
  usb drives/hubs? followed by
        (missing dracut... line)
  No root device found
  Boot has failed, sleeping forever.   (when it does not boot)

Grub, typical entry:
title Fedora (2.6.35)
	root (hd0,0)
	kernel /vmlinuz-2.6.35 ro
root=UUID=686dc496-8814-4c36-8fb7-5ded2916e825 rhgb
SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
rdblacklist=nouveau init=/sbin/bootchartd
	initrd /initramfs-2.6.35.img


My boot failure seems to be different than other two reported
in the thread "2.6.35-rc6-git6: Reported regressions from 2.6.34"
under Bug #16173 and #16228
 http://lkml.indiana.edu/hypermail/linux/kernel/1008.0/00080.html

System is up to date Fedora 12 on Asus P5B Deluxe, Core2 6600 2.4GHz

00:1f.2 SATA controller: Intel Corporation 82801HR/HO/HH (ICH8R/DO/DH)
    6 port SATA AHCI Controller (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce 7600
    GT] (rev a1)
03:00.0 SATA controller: JMicron Technologies, Inc. 20360/20363 Serial
    ATA Controller (rev 02)

Using 2.6.34.1 shows
# lsmod | grep ata
ata_generic             3427  0 
pata_acpi               3227  0 
pata_jmicron            2547  0 
libata                157450  4 ata_generic,pata_acpi,pata_jmicron,ahci
scsi_mod              147895  5 sg,sd_mod,sr_mod,usb_storage,libata

The .config's were made from 2.6.34.1/.config using oldconfig and enter
key (defaults for any questions).

Updating BIOS from 1232 to 1238 (latest) gave no change.
Tried gcc's 4.4.4, 4.5.0, and 4.5.1 with no change.

Thanks for any help,
Don

Re: Linux 2.6.35

[Randy Dunlap]

On Sun, 01 Aug 2010 22:31:02 -0400 Donald Parsons wrote:

> 2.6.35 still fails to boot for me, as first reported here:
>  http://lkml.indiana.edu/hypermail/linux/kernel/1007.3/01144.html
> 
> I've manually bisected it down to around May 20 between
>   2.6.34-git4 (boots) and 2.6.34-git5 (boot fails)
> Also -git[23] boot, and -git8, -rc[126], rc6-git[136] all fail.
> 
> Unfortunately first time I tried was with 2.6.35-rc6 and
> it failed to boot.
> 
> Failure when switching from initramfs to real /root?
> Removing kernel "quiet" param appears to show several
> lines listing:
> 
>   usb drives/hubs? followed by
>   dracut switching root (when booting works)
>               or
>   usb drives/hubs? followed by
>         (missing dracut... line)
>   No root device found
>   Boot has failed, sleeping forever.   (when it does not boot)
> 
> Grub, typical entry:
> title Fedora (2.6.35)
> 	root (hd0,0)
> 	kernel /vmlinuz-2.6.35 ro
> root=UUID=686dc496-8814-4c36-8fb7-5ded2916e825 rhgb
> SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
> rdblacklist=nouveau init=/sbin/bootchartd
> 	initrd /initramfs-2.6.35.img
> 
> 
> My boot failure seems to be different than other two reported
> in the thread "2.6.35-rc6-git6: Reported regressions from 2.6.34"
> under Bug #16173 and #16228
>  http://lkml.indiana.edu/hypermail/linux/kernel/1008.0/00080.html
> 
> System is up to date Fedora 12 on Asus P5B Deluxe, Core2 6600 2.4GHz
> 
> 00:1f.2 SATA controller: Intel Corporation 82801HR/HO/HH (ICH8R/DO/DH)
>     6 port SATA AHCI Controller (rev 02)
> 01:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce 7600
>     GT] (rev a1)
> 03:00.0 SATA controller: JMicron Technologies, Inc. 20360/20363 Serial
>     ATA Controller (rev 02)
> 
> Using 2.6.34.1 shows
> # lsmod | grep ata
> ata_generic             3427  0 
> pata_acpi               3227  0 
> pata_jmicron            2547  0 
> libata                157450  4 ata_generic,pata_acpi,pata_jmicron,ahci
> scsi_mod              147895  5 sg,sd_mod,sr_mod,usb_storage,libata
> 
> The .config's were made from 2.6.34.1/.config using oldconfig and enter
> key (defaults for any questions).

Please post the 2.6.35 .config file.


> Updating BIOS from 1232 to 1238 (latest) gave no change.
> Tried gcc's 4.4.4, 4.5.0, and 4.5.1 with no change.
> 
> Thanks for any help,
> Don

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: Linux 2.6.35

[Bjorn Helgaas]

On Sunday, August 01, 2010 08:31:02 pm Donald Parsons wrote:
> 2.6.35 still fails to boot for me, as first reported here:
>  http://lkml.indiana.edu/hypermail/linux/kernel/1007.3/01144.html
> 
> I've manually bisected it down to around May 20 between
>   2.6.34-git4 (boots) and 2.6.34-git5 (boot fails)
> Also -git[23] boot, and -git8, -rc[126], rc6-git[136] all fail.
> 
> Unfortunately first time I tried was with 2.6.35-rc6 and
> it failed to boot.
> 
> Failure when switching from initramfs to real /root?
> Removing kernel "quiet" param appears to show several
> lines listing:
> 
>   usb drives/hubs? followed by
>   dracut switching root (when booting works)
>               or
>   usb drives/hubs? followed by
>         (missing dracut... line)
>   No root device found
>   Boot has failed, sleeping forever.   (when it does not boot)
> 
> Grub, typical entry:
> title Fedora (2.6.35)
> 	root (hd0,0)
> 	kernel /vmlinuz-2.6.35 ro
> root=UUID=686dc496-8814-4c36-8fb7-5ded2916e825 rhgb
> SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
> rdblacklist=nouveau init=/sbin/bootchartd
> 	initrd /initramfs-2.6.35.img
> 
> 
> My boot failure seems to be different than other two reported
> in the thread "2.6.35-rc6-git6: Reported regressions from 2.6.34"
> under Bug #16173 and #16228

Will it boot with the "pci=nocrs" option?  If so, please open a
report at https://bugzilla.kernel.org, mark it a regression, assign
it to me, and attach the complete dmesg log.  And please respond to
this thread with a pointer to the bugzilla.

Otherwise, a complete console log should have a clue.  The best
thing would be a log from a serial console or netconsole, with
"ignore_loglevel".

Thanks a lot for your report!

Bjorn

Re: Linux 2.6.35

[Donald Parsons]

On Sun, 2010-08-01 at 21:38 -0600, Bjorn Helgaas wrote:
> On Sunday, August 01, 2010 08:31:02 pm Donald Parsons wrote:
> > 2.6.35 still fails to boot for me, as first reported here:
> >  http://lkml.indiana.edu/hypermail/linux/kernel/1007.3/01144.html
> > 
> > I've manually bisected it down to around May 20 between
> >   2.6.34-git4 (boots) and 2.6.34-git5 (boot fails)
> > Also -git[23] boot, and -git8, -rc[126], rc6-git[136] all fail.
> > 
> > Unfortunately first time I tried was with 2.6.35-rc6 and
> > it failed to boot.
> > 
> > Failure when switching from initramfs to real /root?
> > Removing kernel "quiet" param appears to show several
> > lines listing:
> > 
> >   usb drives/hubs? followed by
> >   dracut switching root (when booting works)
> >               or
> >   usb drives/hubs? followed by
> >         (missing dracut... line)
> >   No root device found
> >   Boot has failed, sleeping forever.   (when it does not boot)
> > 
> > Grub, typical entry:
> > title Fedora (2.6.35)
> > 	root (hd0,0)
> > 	kernel /vmlinuz-2.6.35 ro
> > root=UUID=686dc496-8814-4c36-8fb7-5ded2916e825 rhgb
> > SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
> > rdblacklist=nouveau init=/sbin/bootchartd
> > 	initrd /initramfs-2.6.35.img
> > 
> > 
> > My boot failure seems to be different than other two reported
> > in the thread "2.6.35-rc6-git6: Reported regressions from 2.6.34"
> > under Bug #16173 and #16228
> 
> Will it boot with the "pci=nocrs" option?  If so, please open a

No, I tried this on a few attempts when I saw it mentioned under
bug #16228.  But it had no effect/benefit.  Sorry, I should have
mentioned this.

> report at https://bugzilla.kernel.org, mark it a regression, assign
> it to me, and attach the complete dmesg log.  And please respond to
> this thread with a pointer to the bugzilla.
> 
> Otherwise, a complete console log should have a clue.  The best
> thing would be a log from a serial console or netconsole, with
> "ignore_loglevel".

Maybe I will try netconsole tomorrow.  But is Ethernet up when
this boot failure happens?  I think not, since initramfs should
not need networking.

Should I try building sata driver into kernel?  Oh, I am using
ext3, and fdisk -l shows:

Disk /dev/sda: 320.1 GB, 320072933376 bytes
   Device Boot  Start       End      Blocks   Id  System
/dev/sda1   *      1        50      401593+  83  Linux  (/boot)
/dev/sda2          51      7051    56235532+  83  Linux  (/)
/dev/sda3        7052      8377    10651095   82  Linux swap
/dev/sda4        8378     38913   245280420   83  Linux  ()
Disk /dev/sdb: 750.2 GB, 750156374016 bytes
/dev/sdb1          1     91201   732572001   83  Linux  (/home)

> Thanks a lot for your report!
> 
> Bjorn

And thanks for your interest!
Don

Re: Linux 2.6.35

[Bjorn Helgaas]

On Sunday, August 01, 2010 10:21:16 pm Donald Parsons wrote:
> On Sun, 2010-08-01 at 21:38 -0600, Bjorn Helgaas wrote:
> > On Sunday, August 01, 2010 08:31:02 pm Donald Parsons wrote:
> > > 2.6.35 still fails to boot for me, as first reported here:
> > >  http://lkml.indiana.edu/hypermail/linux/kernel/1007.3/01144.html
> > > 
> > > I've manually bisected it down to around May 20 between
> > >   2.6.34-git4 (boots) and 2.6.34-git5 (boot fails)
> > > Also -git[23] boot, and -git8, -rc[126], rc6-git[136] all fail.
> > > 
> > > Unfortunately first time I tried was with 2.6.35-rc6 and
> > > it failed to boot.
> > > 
> > > Failure when switching from initramfs to real /root?
> > > Removing kernel "quiet" param appears to show several
> > > lines listing:
> > > 
> > >   usb drives/hubs? followed by
> > >   dracut switching root (when booting works)
> > >               or
> > >   usb drives/hubs? followed by
> > >         (missing dracut... line)
> > >   No root device found
> > >   Boot has failed, sleeping forever.   (when it does not boot)
> > > 
> > > Grub, typical entry:
> > > title Fedora (2.6.35)
> > > 	root (hd0,0)
> > > 	kernel /vmlinuz-2.6.35 ro
> > > root=UUID=686dc496-8814-4c36-8fb7-5ded2916e825 rhgb
> > > SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
> > > rdblacklist=nouveau init=/sbin/bootchartd
> > > 	initrd /initramfs-2.6.35.img
> > > 
> > > 
> > > My boot failure seems to be different than other two reported
> > > in the thread "2.6.35-rc6-git6: Reported regressions from 2.6.34"
> > > under Bug #16173 and #16228
> > 
> > Will it boot with the "pci=nocrs" option?  If so, please open a
> 
> No, I tried this on a few attempts when I saw it mentioned under
> bug #16228.  But it had no effect/benefit.  Sorry, I should have
> mentioned this.
> 
> > report at https://bugzilla.kernel.org, mark it a regression, assign
> > it to me, and attach the complete dmesg log.  And please respond to
> > this thread with a pointer to the bugzilla.
> > 
> > Otherwise, a complete console log should have a clue.  The best
> > thing would be a log from a serial console or netconsole, with
> > "ignore_loglevel".
> 
> Maybe I will try netconsole tomorrow.  But is Ethernet up when
> this boot failure happens?  I think not, since initramfs should
> not need networking.

Netconsole has special kernel support that doesn't require the normal
networking stack to be configured, so it works quite early.  You
would want to build your networking driver into the kernel for the
most benefit.

If that doesn't work, you could try capturing the log on VGA with a
digital camera or video camera, possibly with "boot_delay=" to
slow things down.

> Should I try building sata driver into kernel?

I doubt that will make a difference.  It seems like the problem
is that we don't find your root filesystem, probably because there's
something wrong with the HBA leading to that device.  For example,
maybe the PCI core mistakenly moved or disabled the adapter, or
there's some problem with its interrupt.

Bjorn

Re: Linux 2.6.35

[Harald Hoyer]

Dracut does not include the SATA module by default. Either force
dracut to include the module in the initramfs, or use build it in the
Kernel.

Am 02.08.2010 um 15:48 schrieb Bjorn Helgaas <bjorn.helgaas@hp.com>:

> On Sunday, August 01, 2010 10:21:16 pm Donald Parsons wrote:
>> On Sun, 2010-08-01 at 21:38 -0600, Bjorn Helgaas wrote:
>>> On Sunday, August 01, 2010 08:31:02 pm Donald Parsons wrote:
>>>> 2.6.35 still fails to boot for me, as first reported here:
>>>> http://lkml.indiana.edu/hypermail/linux/kernel/1007.3/01144.html
>>>>
>>>> I've manually bisected it down to around May 20 between
>>>>  2.6.34-git4 (boots) and 2.6.34-git5 (boot fails)
>>>> Also -git[23] boot, and -git8, -rc[126], rc6-git[136] all fail.
>>>>
>>>> Unfortunately first time I tried was with 2.6.35-rc6 and
>>>> it failed to boot.
>>>>
>>>> Failure when switching from initramfs to real /root?
>>>> Removing kernel "quiet" param appears to show several
>>>> lines listing:
>>>>
>>>>  usb drives/hubs? followed by
>>>>  dracut switching root (when booting works)
>>>>              or
>>>>  usb drives/hubs? followed by
>>>>        (missing dracut... line)
>>>>  No root device found
>>>>  Boot has failed, sleeping forever.   (when it does not boot)
>>>>
>>>> Grub, typical entry:
>>>> title Fedora (2.6.35)
>>>> 	root (hd0,0)
>>>> 	kernel /vmlinuz-2.6.35 ro
>>>> root=UUID=686dc496-8814-4c36-8fb7-5ded2916e825 rhgb
>>>> SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
>>>> rdblacklist=nouveau init=/sbin/bootchartd
>>>> 	initrd /initramfs-2.6.35.img
>>>>
>>>>
>>>> My boot failure seems to be different than other two reported
>>>> in the thread "2.6.35-rc6-git6: Reported regressions from 2.6.34"
>>>> under Bug #16173 and #16228
>>>
>>> Will it boot with the "pci=nocrs" option?  If so, please open a
>>
>> No, I tried this on a few attempts when I saw it mentioned under
>> bug #16228.  But it had no effect/benefit.  Sorry, I should have
>> mentioned this.
>>
>>> report at https://bugzilla.kernel.org, mark it a regression, assign
>>> it to me, and attach the complete dmesg log.  And please respond to
>>> this thread with a pointer to the bugzilla.
>>>
>>> Otherwise, a complete console log should have a clue.  The best
>>> thing would be a log from a serial console or netconsole, with
>>> "ignore_loglevel".
>>
>> Maybe I will try netconsole tomorrow.  But is Ethernet up when
>> this boot failure happens?  I think not, since initramfs should
>> not need networking.
>
> Netconsole has special kernel support that doesn't require the normal
> networking stack to be configured, so it works quite early.  You
> would want to build your networking driver into the kernel for the
> most benefit.
>
> If that doesn't work, you could try capturing the log on VGA with a
> digital camera or video camera, possibly with "boot_delay=" to
> slow things down.
>
>> Should I try building sata driver into kernel?
>
> I doubt that will make a difference.  It seems like the problem
> is that we don't find your root filesystem, probably because there's
> something wrong with the HBA leading to that device.  For example,
> maybe the PCI core mistakenly moved or disabled the adapter, or
> there's some problem with its interrupt.
>
> Bjorn
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.35

[Frédéric L. W. Meunier]

Am I missing something ?

make[2]: *** No rule to make target `firmware/radeon/R100_cp.bin', needed by `__fw_modbuild'.  Stop.

Not sure if it's because I use O= during make, or because I 
always patch the kernel, instead of using the tarball every 
release, or something else.

In linux-2.6.35/firmware/radeon there are R100_cp.bin.ihex and 
other files dated 20091122. 2.6.34 and earlier never gave such 
error.

Re: Linux 2.6.35

[Frédéric L. W. Meunier]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 542 bytes --]

On Mon, 2 Aug 2010, Frédéric L. W. Meunier wrote:

> Am I missing something ?
>
> make[2]: *** No rule to make target `firmware/radeon/R100_cp.bin', needed by 
> `__fw_modbuild'.  Stop.
>
> Not sure if it's because I use O= during make, or because I always patch the 
> kernel, instead of using the tarball every release, or something else.
>
> In linux-2.6.35/firmware/radeon there are R100_cp.bin.ihex and other files 
> dated 20091122. 2.6.34 and earlier never gave such error.

Well, I guess the problem is make 3.82. It worked with 3.81.

Re: Linux 2.6.35

[Donald Parsons]

On Mon, 2010-08-02 at 07:48 -0600, Bjorn Helgaas wrote:

> Netconsole has special kernel support that doesn't require the normal
> networking stack to be configured, so it works quite early.  You
> would want to build your networking driver into the kernel for the
> most benefit.

I compiled network module sky2 and netconsole into kernel 2.6.35.

Inserted into kernel line:
"debug netconsole=192.168.1.10/eth0,192.168.1.5/00:11:25:aa:79:f7"

and ran on a laptop the cmd:   "nc -l -u 6666"
using all default ports if I read documentation correctly.

This failed to show any output at all. 

> If that doesn't work, you could try capturing the log on VGA with a
> digital camera or video camera, possibly with "boot_delay=" to
> slow things down.

What or how much do you want shot with my digital camera? I see
maybe 3 or 4 screens fulls go by to where boot fails.

I added "boot_delay=15" for next boot.

> > Should I try building sata driver into kernel?

I think it is already in kernel, since no sata modules load
in a booting kernel (assuming sata is part of module name).

> I doubt that will make a difference.  It seems like the problem
> is that we don't find your root filesystem, probably because there's
> something wrong with the HBA leading to that device.  For example,
> maybe the PCI core mistakenly moved or disabled the adapter, or
> there's some problem with its interrupt.

I only see one sata compiled into kernel: CONFIG_SATA_PMP=y
and I also see no sata's loaded with lsmod in a working
kernel (2.6.34.1).

I am going to rebuild again with CONFIG_SATA_AHCI=y
instead of =m as it is Fedora's config (do not know how
it got changed).   These modules are loaded in 2.6.34.1:

#lsmod | egrep "ata|ahci"
ata_generic     3427  0 
pata_acpi       3227  0 
pata_jmicron    2547  0 
ahci           35887  4 
libata        157450  4 ata_generic,pata_acpi,pata_jmicron,ahci
scsi_mod      147895  5 sg,sr_mod,usb_storage,sd_mod,libata

Thanks,
Don

Re: Linux 2.6.35

[Harald Hoyer]

On Mon, Aug 2, 2010 at 6:21 AM, Donald Parsons <dparsons@brightdsl.net> wrote:
> On Sun, 2010-08-01 at 21:38 -0600, Bjorn Helgaas wrote:
>> On Sunday, August 01, 2010 08:31:02 pm Donald Parsons wrote:
>> > 2.6.35 still fails to boot for me, as first reported here:
>> >  http://lkml.indiana.edu/hypermail/linux/kernel/1007.3/01144.html
>> >
>> > I've manually bisected it down to around May 20 between
>> >   2.6.34-git4 (boots) and 2.6.34-git5 (boot fails)
>> > Also -git[23] boot, and -git8, -rc[126], rc6-git[136] all fail.
>> >
>> > Unfortunately first time I tried was with 2.6.35-rc6 and
>> > it failed to boot.
>> >
>> > Failure when switching from initramfs to real /root?
>> > Removing kernel "quiet" param appears to show several
>> > lines listing:
>> >
>> >   usb drives/hubs? followed by
>> >   dracut switching root (when booting works)
>> >               or
>> >   usb drives/hubs? followed by
>> >         (missing dracut... line)
>> >   No root device found
>> >   Boot has failed, sleeping forever.   (when it does not boot)
>> >
>> > Grub, typical entry:
>> > title Fedora (2.6.35)
>> >     root (hd0,0)
>> >     kernel /vmlinuz-2.6.35 ro
>> > root=UUID=686dc496-8814-4c36-8fb7-5ded2916e825 rhgb
>> > SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
>> > rdblacklist=nouveau init=/sbin/bootchartd
>> >     initrd /initramfs-2.6.35.img
>> >
>> >
>> > My boot failure seems to be different than other two reported
>> > in the thread "2.6.35-rc6-git6: Reported regressions from 2.6.34"
>> > under Bug #16173 and #16228
>>
>> Will it boot with the "pci=nocrs" option?  If so, please open a
>
> No, I tried this on a few attempts when I saw it mentioned under
> bug #16228.  But it had no effect/benefit.  Sorry, I should have
> mentioned this.
>
>> report at https://bugzilla.kernel.org, mark it a regression, assign
>> it to me, and attach the complete dmesg log.  And please respond to
>> this thread with a pointer to the bugzilla.
>>
>> Otherwise, a complete console log should have a clue.  The best
>> thing would be a log from a serial console or netconsole, with
>> "ignore_loglevel".
>
> Maybe I will try netconsole tomorrow.  But is Ethernet up when
> this boot failure happens?  I think not, since initramfs should
> not need networking.
>
> Should I try building sata driver into kernel?  Oh, I am using
> ext3, and fdisk -l shows:

# dracut --add-drivers "sata" ....

or edit /etc/dracut.conf:

add_drivers+=" sata "

Re: Linux 2.6.35

[Donald Parsons]

On Mon, 2010-08-02 at 18:08 +0200, Harald Hoyer wrote: 
> On Mon, Aug 2, 2010 at 6:21 AM, Donald Parsons <dparsons@brightdsl.net> wrote:
> > On Sun, 2010-08-01 at 21:38 -0600, Bjorn Helgaas wrote:
> >> On Sunday, August 01, 2010 08:31:02 pm Donald Parsons wrote:
> >> > 2.6.35 still fails to boot for me, as first reported here:
> >> >  http://lkml.indiana.edu/hypermail/linux/kernel/1007.3/01144.html
> >> >
> >> > I've manually bisected it down to around May 20 between
> >> >   2.6.34-git4 (boots) and 2.6.34-git5 (boot fails)
> >> > Also -git[23] boot, and -git8, -rc[126], rc6-git[136] all fail.
> >> >
> >> > Unfortunately first time I tried was with 2.6.35-rc6 and
> >> > it failed to boot.
> >> >
> >> > Failure when switching from initramfs to real /root?
> >> > Removing kernel "quiet" param appears to show several
> >> > lines listing:
> >> >
> >> >   usb drives/hubs? followed by
> >> >   dracut switching root (when booting works)
> >> >               or
> >> >   usb drives/hubs? followed by
> >> >         (missing dracut... line)
> >> >   No root device found
> >> >   Boot has failed, sleeping forever.   (when it does not boot)
> >> >
> >> > Grub, typical entry:
> >> > title Fedora (2.6.35)
> >> >     root (hd0,0)
> >> >     kernel /vmlinuz-2.6.35 ro
> >> > root=UUID=686dc496-8814-4c36-8fb7-5ded2916e825 rhgb
> >> > SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
> >> > rdblacklist=nouveau init=/sbin/bootchartd
> >> >     initrd /initramfs-2.6.35.img
> >> >
> >> >
> >> > My boot failure seems to be different than other two reported
> >> > in the thread "2.6.35-rc6-git6: Reported regressions from 2.6.34"
> >> > under Bug #16173 and #16228
> >>
> >> Will it boot with the "pci=nocrs" option?  If so, please open a
> >
> > No, I tried this on a few attempts when I saw it mentioned under
> > bug #16228.  But it had no effect/benefit.  Sorry, I should have
> > mentioned this.
> >
> >> report at https://bugzilla.kernel.org, mark it a regression, assign
> >> it to me, and attach the complete dmesg log.  And please respond to
> >> this thread with a pointer to the bugzilla.
> >>
> >> Otherwise, a complete console log should have a clue.  The best
> >> thing would be a log from a serial console or netconsole, with
> >> "ignore_loglevel".
> >
> > Maybe I will try netconsole tomorrow.  But is Ethernet up when
> > this boot failure happens?  I think not, since initramfs should
> > not need networking.
> >
> > Should I try building sata driver into kernel?  Oh, I am using
> > ext3, and fdisk -l shows:
> 
> # dracut --add-drivers "sata" ....
> 
> or edit /etc/dracut.conf:
> 
> add_drivers+=" sata "

But the kernel used to boot with same identical modules before
but not after 2.6.34-git4.
 --------

Using your suggestion as to where the problem lies, I investigated
more deeply and found:

I've now got 2.6.35-rc6-git3 to boot (and almost certainly 2.6.35 final)

Make oldconfig broke at the transition where boot began failed, ie,
between 2.6.34-git4 and 2.6.34-git5.   Even though modules are the
same, boot fails.  If I use gconfig and set CONFIG_SATA_AHCI=y
instead of CONFIG_SATA_AHCI=m it works, except cannot select =y
unless CONFIG_ATA changed from m to y.

So at some point in past, make oldconfig had apparently changed
CONFIG_SATA_AHCI from y to m and system still booted.  But between
2.6.34-git4 and 2.6.34-git5 the ability to boot was lost.

So make oldconfig is not 100% trustworthy in this case.  I do not
know if this is a problem that should be fixed.  Ask if you want
any .config diffs.

I am going to reboot with 2.6.35 to make sure it boots. Yes!

I consider this boot problem solved unless someone wants to
improve "make oldconfig" behavior.

Thanks,
Don

Re: Linux 2.6.35

[Randy Dunlap]

On Mon, 02 Aug 2010 22:31:41 -0400 Donald Parsons wrote:

> On Mon, 2010-08-02 at 18:08 +0200, Harald Hoyer wrote: 
> > On Mon, Aug 2, 2010 at 6:21 AM, Donald Parsons <dparsons@brightdsl.net> wrote:
> > > On Sun, 2010-08-01 at 21:38 -0600, Bjorn Helgaas wrote:
> > >> On Sunday, August 01, 2010 08:31:02 pm Donald Parsons wrote:
> > >> > 2.6.35 still fails to boot for me, as first reported here:
> > >> >  http://lkml.indiana.edu/hypermail/linux/kernel/1007.3/01144.html
> > >> >
> > >> > I've manually bisected it down to around May 20 between
> > >> >   2.6.34-git4 (boots) and 2.6.34-git5 (boot fails)
> > >> > Also -git[23] boot, and -git8, -rc[126], rc6-git[136] all fail.
> > >> >
> > >> > Unfortunately first time I tried was with 2.6.35-rc6 and
> > >> > it failed to boot.
> > >> >
> > >> > Failure when switching from initramfs to real /root?
> > >> > Removing kernel "quiet" param appears to show several
> > >> > lines listing:
> > >> >
> > >> >   usb drives/hubs? followed by
> > >> >   dracut switching root (when booting works)
> > >> >               or
> > >> >   usb drives/hubs? followed by
> > >> >         (missing dracut... line)
> > >> >   No root device found
> > >> >   Boot has failed, sleeping forever.   (when it does not boot)
> > >> >
> > >> > Grub, typical entry:
> > >> > title Fedora (2.6.35)
> > >> >     root (hd0,0)
> > >> >     kernel /vmlinuz-2.6.35 ro
> > >> > root=UUID=686dc496-8814-4c36-8fb7-5ded2916e825 rhgb
> > >> > SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
> > >> > rdblacklist=nouveau init=/sbin/bootchartd
> > >> >     initrd /initramfs-2.6.35.img
> > >> >
> > >> >
> > >> > My boot failure seems to be different than other two reported
> > >> > in the thread "2.6.35-rc6-git6: Reported regressions from 2.6.34"
> > >> > under Bug #16173 and #16228
> > >>
> > >> Will it boot with the "pci=nocrs" option?  If so, please open a
> > >
> > > No, I tried this on a few attempts when I saw it mentioned under
> > > bug #16228.  But it had no effect/benefit.  Sorry, I should have
> > > mentioned this.
> > >
> > >> report at https://bugzilla.kernel.org, mark it a regression, assign
> > >> it to me, and attach the complete dmesg log.  And please respond to
> > >> this thread with a pointer to the bugzilla.
> > >>
> > >> Otherwise, a complete console log should have a clue.  The best
> > >> thing would be a log from a serial console or netconsole, with
> > >> "ignore_loglevel".
> > >
> > > Maybe I will try netconsole tomorrow.  But is Ethernet up when
> > > this boot failure happens?  I think not, since initramfs should
> > > not need networking.
> > >
> > > Should I try building sata driver into kernel?  Oh, I am using
> > > ext3, and fdisk -l shows:
> > 
> > # dracut --add-drivers "sata" ....
> > 
> > or edit /etc/dracut.conf:
> > 
> > add_drivers+=" sata "
> 
> But the kernel used to boot with same identical modules before
> but not after 2.6.34-git4.
>  --------
> 
> Using your suggestion as to where the problem lies, I investigated
> more deeply and found:
> 
> I've now got 2.6.35-rc6-git3 to boot (and almost certainly 2.6.35 final)
> 
> Make oldconfig broke at the transition where boot began failed, ie,
> between 2.6.34-git4 and 2.6.34-git5.   Even though modules are the
> same, boot fails.  If I use gconfig and set CONFIG_SATA_AHCI=y
> instead of CONFIG_SATA_AHCI=m it works, except cannot select =y
> unless CONFIG_ATA changed from m to y.
> 
> So at some point in past, make oldconfig had apparently changed
> CONFIG_SATA_AHCI from y to m and system still booted.  But between
> 2.6.34-git4 and 2.6.34-git5 the ability to boot was lost.
> 
> So make oldconfig is not 100% trustworthy in this case.  I do not
> know if this is a problem that should be fixed.  Ask if you want
> any .config diffs.
> 
> I am going to reboot with 2.6.35 to make sure it boots. Yes!
> 
> I consider this boot problem solved unless someone wants to
> improve "make oldconfig" behavior.

It would be good to be able to explain what you are seeing & describing,
so yes, if you can send a .config file that exhibits the problem, I'd
love to look at it.

thanks,
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: Linux 2.6.35

[Stefan Richter]

Randy Dunlap wrote:
> On Mon, 02 Aug 2010 22:31:41 -0400 Donald Parsons wrote:
>>>>> On Sunday, August 01, 2010 08:31:02 pm Donald Parsons wrote:
>>>>>> 2.6.35 still fails to boot for me, as first reported here:
>>>>>>  http://lkml.indiana.edu/hypermail/linux/kernel/1007.3/01144.html
>>>>>>
>>>>>> I've manually bisected it down to around May 20 between
>>>>>>   2.6.34-git4 (boots) and 2.6.34-git5 (boot fails)
>>>>>> Also -git[23] boot, and -git8, -rc[126], rc6-git[136] all fail.
[...]

To recap:  Donald uses ata_generic,pata_acpi,pata_jmicron,ahci for Asus
P5B Deluxe which has

00:1f.2 SATA controller: Intel Corporation 82801HB (ICH8) SATA AHCI
Controller (rev 02)
03:00.0 SATA controller: JMicron Technologies, Inc. JMicron 20360/20363
AHCI Controller (rev 02)
03:00.1 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363
AHCI Controller (rev 02)

On which interface is the disk with the root filesystem?

[...]
>> Using your suggestion as to where the problem lies, I investigated
>> more deeply and found:
>>
>> I've now got 2.6.35-rc6-git3 to boot (and almost certainly 2.6.35 final)
>>
>> Make oldconfig broke at the transition where boot began failed, ie,
>> between 2.6.34-git4 and 2.6.34-git5.   Even though modules are the
>> same, boot fails.  If I use gconfig and set CONFIG_SATA_AHCI=y
>> instead of CONFIG_SATA_AHCI=m it works, except cannot select =y
>> unless CONFIG_ATA changed from m to y.
>>
>> So at some point in past, make oldconfig had apparently changed
>> CONFIG_SATA_AHCI from y to m and system still booted.  But between
>> 2.6.34-git4 and 2.6.34-git5 the ability to boot was lost.
>>
>> So make oldconfig is not 100% trustworthy in this case.  I do not
>> know if this is a problem that should be fixed.  Ask if you want
>> any .config diffs.
>>
>> I am going to reboot with 2.6.35 to make sure it boots. Yes!
>>
>> I consider this boot problem solved unless someone wants to
>> improve "make oldconfig" behavior.

There was at least the following notable change in drivers/ata/Kconfig:
Commit 9a7780c9acb821fe1c2b6fc53f74cc2556ff5364 "libata-sff: make BMDMA
optional" added a new intermediary configuration option, ATA_SFF.  The
option PATA_JMICRON depends on this new option now.  ATA_GENERIC,
PATA_ACPI, SATA_AHCI do not depend on it.

("make oldconfig" asks for ATA_BMDMA and defaults to Y, as does the help
text recommend.  Still, people who switch from 2.6.34 to 2.6.35 might be
convied that they do not need it as they already used kernels that did
not have this option with their controllers.)

Might the problem be with the order in which interfaces and disks are
discovered and hence enumerated?

> It would be good to be able to explain what you are seeing & describing,
> so yes, if you can send a .config file that exhibits the problem, I'd
> love to look at it.

Could be enlightening.
-- 
Stefan Richter
-=====-==-=- =--- ---==
http://arcgraph.de/sr/

Re: Linux 2.6.35

[Donald Parsons]

On Tue, 2010-08-03 at 12:24 +0200, Stefan Richter wrote:
> Randy Dunlap wrote:
> > On Mon, 02 Aug 2010 22:31:41 -0400 Donald Parsons wrote:
> >>>>> On Sunday, August 01, 2010 08:31:02 pm Donald Parsons wrote:
> >>>>>> 2.6.35 still fails to boot for me, as first reported here:
> >>>>>>  http://lkml.indiana.edu/hypermail/linux/kernel/1007.3/01144.html
> >>>>>>
> >>>>>> I've manually bisected it down to around May 20 between
> >>>>>>   2.6.34-git4 (boots) and 2.6.34-git5 (boot fails)
> >>>>>> Also -git[23] boot, and -git8, -rc[126], rc6-git[136] all fail.
> [...]
> 
> To recap:  Donald uses ata_generic,pata_acpi,pata_jmicron,ahci for Asus
> P5B Deluxe which has
> 
> 00:1f.2 SATA controller: Intel Corporation 82801HB (ICH8) SATA AHCI
> Controller (rev 02)
> 03:00.0 SATA controller: JMicron Technologies, Inc. JMicron 20360/20363
> AHCI Controller (rev 02)
> 03:00.1 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363
> AHCI Controller (rev 02)
> 
> On which interface is the disk with the root filesystem?

All drives hook to ICH8R, two Seagate SATA hard drives, and
a SATA CD/DVD drive.  JMicron has no drives so far.

Don

Re: Linux 2.6.35

[Donald Parsons]

[-- Attachment #1: Type: text/plain, Size: 9141 bytes --]

Resending to all...
On Mon, 2010-08-02 at 21:42 -0700, Randy Dunlap wrote:
> On Mon, 02 Aug 2010 22:31:41 -0400 Donald Parsons wrote:
> 
> > On Mon, 2010-08-02 at 18:08 +0200, Harald Hoyer wrote: 
> > > On Mon, Aug 2, 2010 at 6:21 AM, Donald Parsons <dparsons@brightdsl.net> wrote:
> > > > On Sun, 2010-08-01 at 21:38 -0600, Bjorn Helgaas wrote:
> > > >> On Sunday, August 01, 2010 08:31:02 pm Donald Parsons wrote:
> > > >> > 2.6.35 still fails to boot for me, as first reported here:
> > > >> >  http://lkml.indiana.edu/hypermail/linux/kernel/1007.3/01144.html
> > > >> >
> > > >> > I've manually bisected it down to around May 20 between
> > > >> >   2.6.34-git4 (boots) and 2.6.34-git5 (boot fails)
> > > >> > Also -git[23] boot, and -git8, -rc[126], rc6-git[136] all fail.
> > > >> >
> > > >> > Unfortunately first time I tried was with 2.6.35-rc6 and
> > > >> > it failed to boot.
> > > >> >
> > > >> > Failure when switching from initramfs to real /root?
> > > >> > Removing kernel "quiet" param appears to show several
> > > >> > lines listing:
> > > >> >
> > > >> >   usb drives/hubs? followed by
> > > >> >   dracut switching root (when booting works)
> > > >> >               or
> > > >> >   usb drives/hubs? followed by
> > > >> >         (missing dracut... line)
> > > >> >   No root device found
> > > >> >   Boot has failed, sleeping forever.   (when it does not boot)
> > > >> >
> > > >> > Grub, typical entry:
> > > >> > title Fedora (2.6.35)
> > > >> >     root (hd0,0)
> > > >> >     kernel /vmlinuz-2.6.35 ro
> > > >> > root=UUID=686dc496-8814-4c36-8fb7-5ded2916e825 rhgb
> > > >> > SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
> > > >> > rdblacklist=nouveau init=/sbin/bootchartd
> > > >> >     initrd /initramfs-2.6.35.img
> > > >> >
> > > >> >
> > > >> > My boot failure seems to be different than other two reported
> > > >> > in the thread "2.6.35-rc6-git6: Reported regressions from 2.6.34"
> > > >> > under Bug #16173 and #16228
> > > >>
> > > >> Will it boot with the "pci=nocrs" option?  If so, please open a
> > > >
> > > > No, I tried this on a few attempts when I saw it mentioned under
> > > > bug #16228.  But it had no effect/benefit.  Sorry, I should have
> > > > mentioned this.
> > > >
> > > >> report at https://bugzilla.kernel.org, mark it a regression, assign
> > > >> it to me, and attach the complete dmesg log.  And please respond to
> > > >> this thread with a pointer to the bugzilla.
> > > >>
> > > >> Otherwise, a complete console log should have a clue.  The best
> > > >> thing would be a log from a serial console or netconsole, with
> > > >> "ignore_loglevel".
> > > >
> > > > Maybe I will try netconsole tomorrow.  But is Ethernet up when
> > > > this boot failure happens?  I think not, since initramfs should
> > > > not need networking.
> > > >
> > > > Should I try building sata driver into kernel?  Oh, I am using
> > > > ext3, and fdisk -l shows:
> > > 
> > > # dracut --add-drivers "sata" ....
> > > 
> > > or edit /etc/dracut.conf:
> > > 
> > > add_drivers+=" sata "
> > 
> > But the kernel used to boot with same identical modules before
> > but not after 2.6.34-git4.
> >  --------
> > 
> > Using your suggestion as to where the problem lies, I investigated
> > more deeply and found:
> > 
> > I've now got 2.6.35-rc6-git3 to boot (and almost certainly 2.6.35 final)
> > 
> > Make oldconfig broke at the transition where boot began failed, ie,
> > between 2.6.34-git4 and 2.6.34-git5.   Even though modules are the
> > same, boot fails.  If I use gconfig and set CONFIG_SATA_AHCI=y
> > instead of CONFIG_SATA_AHCI=m it works, except cannot select =y
> > unless CONFIG_ATA changed from m to y.
> > 
> > So at some point in past, make oldconfig had apparently changed
> > CONFIG_SATA_AHCI from y to m and system still booted.  But between
> > 2.6.34-git4 and 2.6.34-git5 the ability to boot was lost.
> > 
> > So make oldconfig is not 100% trustworthy in this case.  I do not
> > know if this is a problem that should be fixed.  Ask if you want
> > any .config diffs.
> > 
> > I am going to reboot with 2.6.35 to make sure it boots. Yes!
> > 
> > I consider this boot problem solved unless someone wants to
> > improve "make oldconfig" behavior.
> 
> It would be good to be able to explain what you are seeing & describing,
> so yes, if you can send a .config file that exhibits the problem, I'd
> love to look at it.
> 
> thanks,
> ---
> ~Randy


Okay, here is the diff between 2.6.34-git4 and 2.6.34-git5
It should be equivalent to make silentoldconfig as I made no
changes, just enter to accept defaults.  The git4 boots and
git5 does not boot.     (Both based off 2.6.34.1.config)

(and attached config-2.6.34-git4.gz, because .config was too
 big for mail list last time.)

--- config-2.6.34-git4  2010-08-01 19:52:48.000000000 -0400
+++ config-2.6.34-git5  2010-08-01 18:10:14.000000000 -0400
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.34-git4
-# Sun Aug  1 19:52:48 2010
+# Linux kernel version: 2.6.34-git5
+# Sun Aug  1 18:10:14 2010
 #
 CONFIG_64BIT=y
 # CONFIG_X86_32 is not set
@@ -544,7 +544,7 @@
 CONFIG_YENTA_TOSHIBA=y
 CONFIG_PD6729=m
 CONFIG_I82092=m
-CONFIG_PCCARD_NONSTATIC=m
+CONFIG_PCCARD_NONSTATIC=y
 CONFIG_HOTPLUG_PCI=y
 CONFIG_HOTPLUG_PCI_FAKE=m
 CONFIG_HOTPLUG_PCI_ACPI=m
@@ -1474,7 +1474,9 @@
 CONFIG_ATA_ACPI=y
 CONFIG_SATA_PMP=y
 CONFIG_SATA_AHCI=m
+# CONFIG_SATA_AHCI_PLATFORM is not set
 CONFIG_SATA_SIL24=m
+CONFIG_SATA_INIC162X=m
 CONFIG_ATA_SFF=y
 CONFIG_SATA_SVW=m
 CONFIG_ATA_PIIX=m
@@ -1489,7 +1491,6 @@
 CONFIG_SATA_ULI=m
 CONFIG_SATA_VIA=m
 CONFIG_SATA_VITESSE=m
-CONFIG_SATA_INIC162X=m
 CONFIG_PATA_ACPI=m
 CONFIG_PATA_ALI=m
 CONFIG_PATA_AMD=m
@@ -1882,6 +1883,7 @@
 CONFIG_KEYBOARD_ATKBD=y
 # CONFIG_QT2160 is not set
 # CONFIG_KEYBOARD_LKKBD is not set
+# CONFIG_KEYBOARD_TCA6416 is not set
 # CONFIG_KEYBOARD_LM8323 is not set
 # CONFIG_KEYBOARD_MAX7359 is not set
 # CONFIG_KEYBOARD_NEWTON is not set
@@ -1944,6 +1946,7 @@
 # CONFIG_TOUCHSCREEN_AD7879_I2C is not set
 # CONFIG_TOUCHSCREEN_AD7879 is not set
 # CONFIG_TOUCHSCREEN_DYNAPRO is not set
+# CONFIG_TOUCHSCREEN_HAMPSHIRE is not set
 # CONFIG_TOUCHSCREEN_EETI is not set
 CONFIG_TOUCHSCREEN_FUJITSU=m
 CONFIG_TOUCHSCREEN_GUNZE=m
@@ -1977,6 +1980,7 @@
 # CONFIG_TOUCHSCREEN_TOUCHIT213 is not set
 # CONFIG_TOUCHSCREEN_TSC2007 is not set
 CONFIG_INPUT_MISC=y
+# CONFIG_INPUT_AD714X is not set
 CONFIG_INPUT_PCSPKR=m
 CONFIG_INPUT_APANEL=m
 CONFIG_INPUT_ATLAS_BTNS=m
@@ -1988,6 +1992,7 @@
 # CONFIG_INPUT_CM109 is not set
 CONFIG_INPUT_UINPUT=m
 # CONFIG_INPUT_WINBOND_CIR is not set
+# CONFIG_INPUT_PCF8574 is not set
 
 #
 # Hardware I/O ports
@@ -2377,7 +2382,6 @@
 # CONFIG_HTC_PASIC3 is not set
 # CONFIG_MFD_TMIO is not set
 # CONFIG_MFD_WM8400 is not set
-# CONFIG_MFD_WM8994 is not set
 # CONFIG_MFD_PCF50633 is not set
 # CONFIG_LPC_SCH is not set
 # CONFIG_REGULATOR is not set
@@ -2398,6 +2402,13 @@
 #
 CONFIG_IR_CORE=m
 CONFIG_VIDEO_IR=m
+CONFIG_RC_MAP=m
+CONFIG_IR_NEC_DECODER=m
+CONFIG_IR_RC5_DECODER=m
+CONFIG_IR_RC6_DECODER=m
+CONFIG_IR_JVC_DECODER=m
+CONFIG_IR_SONY_DECODER=m
+# CONFIG_IR_IMON is not set
 # CONFIG_MEDIA_ATTACH is not set
 CONFIG_MEDIA_TUNER=m
 # CONFIG_MEDIA_TUNER_CUSTOMISE is not set
@@ -2416,8 +2427,8 @@
 # CONFIG_VIDEO_FIXED_MINOR_RANGES is not set
 CONFIG_VIDEO_HELPER_CHIPS_AUTO=y
 CONFIG_VIDEO_IR_I2C=m
-# CONFIG_VIDEO_VIVI is not set
 # CONFIG_VIDEO_BT848 is not set
+# CONFIG_VIDEO_W9966 is not set
 # CONFIG_VIDEO_SAA5246A is not set
 # CONFIG_VIDEO_SAA5249 is not set
 # CONFIG_VIDEO_ZORAN is not set
@@ -2477,10 +2488,10 @@
 # CONFIG_USB_ET61X251 is not set
 # CONFIG_USB_SN9C102 is not set
 # CONFIG_USB_ZC0301 is not set
-CONFIG_USB_PWC_INPUT_EVDEV=y
 # CONFIG_USB_ZR364XX is not set
 # CONFIG_USB_STKWEBCAM is not set
 # CONFIG_USB_S2255 is not set
+# CONFIG_V4L_MEM2MEM_DRIVERS is not set
 CONFIG_RADIO_ADAPTERS=y
 # CONFIG_RADIO_GEMTEK_PCI is not set
 # CONFIG_RADIO_MAXIRADIO is not set
@@ -2695,6 +2706,7 @@
 CONFIG_SND_ALS300=m
 CONFIG_SND_ALS4000=m
 CONFIG_SND_ALI5451=m
+# CONFIG_SND_ASIHPI is not set
 CONFIG_SND_ATIIXP=m
 CONFIG_SND_ATIIXP_MODEM=m
 CONFIG_SND_AU8810=m
@@ -2734,6 +2746,7 @@
 CONFIG_SND_ENS1371=m
 CONFIG_SND_ES1938=m
 CONFIG_SND_ES1968=m
+# CONFIG_SND_ES1968_INPUT is not set
 CONFIG_SND_FM801=m
 # CONFIG_SND_FM801_TEA575X_BOOL is not set
 CONFIG_SND_HDA_INTEL=m
@@ -2769,6 +2782,7 @@
 CONFIG_SND_KORG1212=m
 # CONFIG_SND_LX6464ES is not set
 CONFIG_SND_MAESTRO3=m
+# CONFIG_SND_MAESTRO3_INPUT is not set
 CONFIG_SND_MIXART=m
 CONFIG_SND_NM256=m
 CONFIG_SND_PCXHR=m
@@ -3148,10 +3162,6 @@
 # CONFIG_UIO_SERCOS3 is not set
 # CONFIG_UIO_PCI_GENERIC is not set
 # CONFIG_UIO_NETX is not set
-
-#
-# TI VLYNQ
-#
 # CONFIG_STAGING is not set
 CONFIG_X86_PLATFORM_DEVICES=y
 # CONFIG_ACER_WMI is not set

-------------------------------------------

Can possibly duplicate problem if you have a 
sata based PC from last few years.

Set  CONFIG_ATA=m
and this becomes CONFIG_SATA_AHCI=m  (cannot select=y)

Then 2.6.34.[01] (probably 2 also) will boot.
Make silentoldconfig with this .config and see
that 2.6.35 will not boot.

Thanks,
Don



[-- Attachment #2: config-2.6.34-git4.gz --]
[-- Type: application/x-gzip, Size: 22546 bytes --]

Re: Linux 2.6.35

[Randy Dunlap]

On Tue, 03 Aug 2010 12:26:50 -0400 Donald Parsons wrote:

> Resending to all...
> On Mon, 2010-08-02 at 21:42 -0700, Randy Dunlap wrote:
> > On Mon, 02 Aug 2010 22:31:41 -0400 Donald Parsons wrote:
> > 
> > > On Mon, 2010-08-02 at 18:08 +0200, Harald Hoyer wrote: 
> > > > On Mon, Aug 2, 2010 at 6:21 AM, Donald Parsons <dparsons@brightdsl.net> wrote:
> > > > > On Sun, 2010-08-01 at 21:38 -0600, Bjorn Helgaas wrote:
> > > > >> On Sunday, August 01, 2010 08:31:02 pm Donald Parsons wrote:
> > > > >> > 2.6.35 still fails to boot for me, as first reported here:
> > > > >> >  http://lkml.indiana.edu/hypermail/linux/kernel/1007.3/01144.html
> > > > >> >
> > > > >> > I've manually bisected it down to around May 20 between
> > > > >> >   2.6.34-git4 (boots) and 2.6.34-git5 (boot fails)
> > > > >> > Also -git[23] boot, and -git8, -rc[126], rc6-git[136] all fail.
> > > > >> >
> > > > >> > Unfortunately first time I tried was with 2.6.35-rc6 and
> > > > >> > it failed to boot.
> > > > >> >
> > > > >> > Failure when switching from initramfs to real /root?
> > > > >> > Removing kernel "quiet" param appears to show several
> > > > >> > lines listing:
> > > > >> >
> > > > >> >   usb drives/hubs? followed by
> > > > >> >   dracut switching root (when booting works)
> > > > >> >               or
> > > > >> >   usb drives/hubs? followed by
> > > > >> >         (missing dracut... line)
> > > > >> >   No root device found
> > > > >> >   Boot has failed, sleeping forever.   (when it does not boot)
> > > > >> >
> > > > >> > Grub, typical entry:
> > > > >> > title Fedora (2.6.35)
> > > > >> >     root (hd0,0)
> > > > >> >     kernel /vmlinuz-2.6.35 ro
> > > > >> > root=UUID=686dc496-8814-4c36-8fb7-5ded2916e825 rhgb
> > > > >> > SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
> > > > >> > rdblacklist=nouveau init=/sbin/bootchartd
> > > > >> >     initrd /initramfs-2.6.35.img
> > > > >> >
> > > > >> >
> > > > >> > My boot failure seems to be different than other two reported
> > > > >> > in the thread "2.6.35-rc6-git6: Reported regressions from 2.6.34"
> > > > >> > under Bug #16173 and #16228
> > > > >>
> > > > >> Will it boot with the "pci=nocrs" option?  If so, please open a
> > > > >
> > > > > No, I tried this on a few attempts when I saw it mentioned under
> > > > > bug #16228.  But it had no effect/benefit.  Sorry, I should have
> > > > > mentioned this.
> > > > >
> > > > >> report at https://bugzilla.kernel.org, mark it a regression, assign
> > > > >> it to me, and attach the complete dmesg log.  And please respond to
> > > > >> this thread with a pointer to the bugzilla.
> > > > >>
> > > > >> Otherwise, a complete console log should have a clue.  The best
> > > > >> thing would be a log from a serial console or netconsole, with
> > > > >> "ignore_loglevel".
> > > > >
> > > > > Maybe I will try netconsole tomorrow.  But is Ethernet up when
> > > > > this boot failure happens?  I think not, since initramfs should
> > > > > not need networking.
> > > > >
> > > > > Should I try building sata driver into kernel?  Oh, I am using
> > > > > ext3, and fdisk -l shows:
> > > > 
> > > > # dracut --add-drivers "sata" ....
> > > > 
> > > > or edit /etc/dracut.conf:
> > > > 
> > > > add_drivers+=" sata "
> > > 
> > > But the kernel used to boot with same identical modules before
> > > but not after 2.6.34-git4.
> > >  --------
> > > 
> > > Using your suggestion as to where the problem lies, I investigated
> > > more deeply and found:
> > > 
> > > I've now got 2.6.35-rc6-git3 to boot (and almost certainly 2.6.35 final)
> > > 
> > > Make oldconfig broke at the transition where boot began failed, ie,
> > > between 2.6.34-git4 and 2.6.34-git5.   Even though modules are the
> > > same, boot fails.  If I use gconfig and set CONFIG_SATA_AHCI=y
> > > instead of CONFIG_SATA_AHCI=m it works, except cannot select =y
> > > unless CONFIG_ATA changed from m to y.
> > > 
> > > So at some point in past, make oldconfig had apparently changed
> > > CONFIG_SATA_AHCI from y to m and system still booted.  But between
> > > 2.6.34-git4 and 2.6.34-git5 the ability to boot was lost.
> > > 
> > > So make oldconfig is not 100% trustworthy in this case.  I do not
> > > know if this is a problem that should be fixed.  Ask if you want
> > > any .config diffs.
> > > 
> > > I am going to reboot with 2.6.35 to make sure it boots. Yes!
> > > 
> > > I consider this boot problem solved unless someone wants to
> > > improve "make oldconfig" behavior.
> > 
> > It would be good to be able to explain what you are seeing & describing,
> > so yes, if you can send a .config file that exhibits the problem, I'd
> > love to look at it.
> > 
> > thanks,
> > ---
> > ~Randy
> 
> 
> Okay, here is the diff between 2.6.34-git4 and 2.6.34-git5
> It should be equivalent to make silentoldconfig as I made no
> changes, just enter to accept defaults.  The git4 boots and
> git5 does not boot.     (Both based off 2.6.34.1.config)

Yes, I had just generated this same diff.
The only config change that could remotely make a difference is:
> +# CONFIG_SATA_AHCI_PLATFORM is not set

and I don't see how it could matter.

> (and attached config-2.6.34-git4.gz, because .config was too
>  big for mail list last time.)

Last time being recently?  lkml accepts email sizes (with attachments)
up to 300 KB, IIRC.


> --- config-2.6.34-git4  2010-08-01 19:52:48.000000000 -0400
> +++ config-2.6.34-git5  2010-08-01 18:10:14.000000000 -0400
> @@ -1,7 +1,7 @@
>  #
>  # Automatically generated make config: don't edit
> -# Linux kernel version: 2.6.34-git4
> -# Sun Aug  1 19:52:48 2010
> +# Linux kernel version: 2.6.34-git5
> +# Sun Aug  1 18:10:14 2010
>  #
>  CONFIG_64BIT=y
>  # CONFIG_X86_32 is not set
> @@ -544,7 +544,7 @@
>  CONFIG_YENTA_TOSHIBA=y
>  CONFIG_PD6729=m
>  CONFIG_I82092=m
> -CONFIG_PCCARD_NONSTATIC=m
> +CONFIG_PCCARD_NONSTATIC=y
>  CONFIG_HOTPLUG_PCI=y
>  CONFIG_HOTPLUG_PCI_FAKE=m
>  CONFIG_HOTPLUG_PCI_ACPI=m
> @@ -1474,7 +1474,9 @@
>  CONFIG_ATA_ACPI=y
>  CONFIG_SATA_PMP=y
>  CONFIG_SATA_AHCI=m
> +# CONFIG_SATA_AHCI_PLATFORM is not set
>  CONFIG_SATA_SIL24=m
> +CONFIG_SATA_INIC162X=m
>  CONFIG_ATA_SFF=y
>  CONFIG_SATA_SVW=m
>  CONFIG_ATA_PIIX=m
> @@ -1489,7 +1491,6 @@
>  CONFIG_SATA_ULI=m
>  CONFIG_SATA_VIA=m
>  CONFIG_SATA_VITESSE=m
> -CONFIG_SATA_INIC162X=m
>  CONFIG_PATA_ACPI=m
>  CONFIG_PATA_ALI=m
>  CONFIG_PATA_AMD=m
> @@ -1882,6 +1883,7 @@
>  CONFIG_KEYBOARD_ATKBD=y
>  # CONFIG_QT2160 is not set
>  # CONFIG_KEYBOARD_LKKBD is not set
> +# CONFIG_KEYBOARD_TCA6416 is not set
>  # CONFIG_KEYBOARD_LM8323 is not set
>  # CONFIG_KEYBOARD_MAX7359 is not set
>  # CONFIG_KEYBOARD_NEWTON is not set
> @@ -1944,6 +1946,7 @@
>  # CONFIG_TOUCHSCREEN_AD7879_I2C is not set
>  # CONFIG_TOUCHSCREEN_AD7879 is not set
>  # CONFIG_TOUCHSCREEN_DYNAPRO is not set
> +# CONFIG_TOUCHSCREEN_HAMPSHIRE is not set
>  # CONFIG_TOUCHSCREEN_EETI is not set
>  CONFIG_TOUCHSCREEN_FUJITSU=m
>  CONFIG_TOUCHSCREEN_GUNZE=m
> @@ -1977,6 +1980,7 @@
>  # CONFIG_TOUCHSCREEN_TOUCHIT213 is not set
>  # CONFIG_TOUCHSCREEN_TSC2007 is not set
>  CONFIG_INPUT_MISC=y
> +# CONFIG_INPUT_AD714X is not set
>  CONFIG_INPUT_PCSPKR=m
>  CONFIG_INPUT_APANEL=m
>  CONFIG_INPUT_ATLAS_BTNS=m
> @@ -1988,6 +1992,7 @@
>  # CONFIG_INPUT_CM109 is not set
>  CONFIG_INPUT_UINPUT=m
>  # CONFIG_INPUT_WINBOND_CIR is not set
> +# CONFIG_INPUT_PCF8574 is not set
>  
>  #
>  # Hardware I/O ports
> @@ -2377,7 +2382,6 @@
>  # CONFIG_HTC_PASIC3 is not set
>  # CONFIG_MFD_TMIO is not set
>  # CONFIG_MFD_WM8400 is not set
> -# CONFIG_MFD_WM8994 is not set
>  # CONFIG_MFD_PCF50633 is not set
>  # CONFIG_LPC_SCH is not set
>  # CONFIG_REGULATOR is not set
> @@ -2398,6 +2402,13 @@
>  #
>  CONFIG_IR_CORE=m
>  CONFIG_VIDEO_IR=m
> +CONFIG_RC_MAP=m
> +CONFIG_IR_NEC_DECODER=m
> +CONFIG_IR_RC5_DECODER=m
> +CONFIG_IR_RC6_DECODER=m
> +CONFIG_IR_JVC_DECODER=m
> +CONFIG_IR_SONY_DECODER=m
> +# CONFIG_IR_IMON is not set
>  # CONFIG_MEDIA_ATTACH is not set
>  CONFIG_MEDIA_TUNER=m
>  # CONFIG_MEDIA_TUNER_CUSTOMISE is not set
> @@ -2416,8 +2427,8 @@
>  # CONFIG_VIDEO_FIXED_MINOR_RANGES is not set
>  CONFIG_VIDEO_HELPER_CHIPS_AUTO=y
>  CONFIG_VIDEO_IR_I2C=m
> -# CONFIG_VIDEO_VIVI is not set
>  # CONFIG_VIDEO_BT848 is not set
> +# CONFIG_VIDEO_W9966 is not set
>  # CONFIG_VIDEO_SAA5246A is not set
>  # CONFIG_VIDEO_SAA5249 is not set
>  # CONFIG_VIDEO_ZORAN is not set
> @@ -2477,10 +2488,10 @@
>  # CONFIG_USB_ET61X251 is not set
>  # CONFIG_USB_SN9C102 is not set
>  # CONFIG_USB_ZC0301 is not set
> -CONFIG_USB_PWC_INPUT_EVDEV=y
>  # CONFIG_USB_ZR364XX is not set
>  # CONFIG_USB_STKWEBCAM is not set
>  # CONFIG_USB_S2255 is not set
> +# CONFIG_V4L_MEM2MEM_DRIVERS is not set
>  CONFIG_RADIO_ADAPTERS=y
>  # CONFIG_RADIO_GEMTEK_PCI is not set
>  # CONFIG_RADIO_MAXIRADIO is not set
> @@ -2695,6 +2706,7 @@
>  CONFIG_SND_ALS300=m
>  CONFIG_SND_ALS4000=m
>  CONFIG_SND_ALI5451=m
> +# CONFIG_SND_ASIHPI is not set
>  CONFIG_SND_ATIIXP=m
>  CONFIG_SND_ATIIXP_MODEM=m
>  CONFIG_SND_AU8810=m
> @@ -2734,6 +2746,7 @@
>  CONFIG_SND_ENS1371=m
>  CONFIG_SND_ES1938=m
>  CONFIG_SND_ES1968=m
> +# CONFIG_SND_ES1968_INPUT is not set
>  CONFIG_SND_FM801=m
>  # CONFIG_SND_FM801_TEA575X_BOOL is not set
>  CONFIG_SND_HDA_INTEL=m
> @@ -2769,6 +2782,7 @@
>  CONFIG_SND_KORG1212=m
>  # CONFIG_SND_LX6464ES is not set
>  CONFIG_SND_MAESTRO3=m
> +# CONFIG_SND_MAESTRO3_INPUT is not set
>  CONFIG_SND_MIXART=m
>  CONFIG_SND_NM256=m
>  CONFIG_SND_PCXHR=m
> @@ -3148,10 +3162,6 @@
>  # CONFIG_UIO_SERCOS3 is not set
>  # CONFIG_UIO_PCI_GENERIC is not set
>  # CONFIG_UIO_NETX is not set
> -
> -#
> -# TI VLYNQ
> -#
>  # CONFIG_STAGING is not set
>  CONFIG_X86_PLATFORM_DEVICES=y
>  # CONFIG_ACER_WMI is not set
> 
> -------------------------------------------
> 
> Can possibly duplicate problem if you have a 
> sata based PC from last few years.
> 
> Set  CONFIG_ATA=m

That's already =m in this config file.

> and this becomes CONFIG_SATA_AHCI=m  (cannot select=y)

That's as expected.  CONFIG_ATA value controls CONFIG_SATA_AHCI
possible values.

> 
> Then 2.6.34.[01] (probably 2 also) will boot.
> Make silentoldconfig with this .config and see
> that 2.6.35 will not boot.

So with CONFIG_ATA=m and CONFIG_SATA_AHCI=m, does 2.6.34-git4 boot
but 2.6.34-git5 fails to boot?


thanks,
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: Linux 2.6.35

[Donald Parsons]

On Tue, 2010-08-03 at 09:40 -0700, Randy Dunlap wrote:
> On Tue, 03 Aug 2010 12:26:50 -0400 Donald Parsons wrote:
> 
> > Resending to all...
> > On Mon, 2010-08-02 at 21:42 -0700, Randy Dunlap wrote:
> > > On Mon, 02 Aug 2010 22:31:41 -0400 Donald Parsons wrote:
> > > 
> > > > On Mon, 2010-08-02 at 18:08 +0200, Harald Hoyer wrote: 
> > > > > On Mon, Aug 2, 2010 at 6:21 AM, Donald Parsons <dparsons@brightdsl.net> wrote:
> > > > > > On Sun, 2010-08-01 at 21:38 -0600, Bjorn Helgaas wrote:
> > > > > >> On Sunday, August 01, 2010 08:31:02 pm Donald Parsons wrote:
> > > > > >> > 2.6.35 still fails to boot for me, as first reported here:
> > > > > >> >  http://lkml.indiana.edu/hypermail/linux/kernel/1007.3/01144.html
> > > > > >> >
> > > > > >> > I've manually bisected it down to around May 20 between
> > > > > >> >   2.6.34-git4 (boots) and 2.6.34-git5 (boot fails)
> > > > > >> > Also -git[23] boot, and -git8, -rc[126], rc6-git[136] all fail.
> > > > > >> >
> > > > > >> > Unfortunately first time I tried was with 2.6.35-rc6 and
> > > > > >> > it failed to boot.
> > > > > >> >
> > > > > >> > Failure when switching from initramfs to real /root?
> > > > > >> > Removing kernel "quiet" param appears to show several
> > > > > >> > lines listing:
> > > > > >> >
> > > > > >> >   usb drives/hubs? followed by
> > > > > >> >   dracut switching root (when booting works)
> > > > > >> >               or
> > > > > >> >   usb drives/hubs? followed by
> > > > > >> >         (missing dracut... line)
> > > > > >> >   No root device found
> > > > > >> >   Boot has failed, sleeping forever.   (when it does not boot)
> > > > > >> >
> > > > > >> > Grub, typical entry:
> > > > > >> > title Fedora (2.6.35)
> > > > > >> >     root (hd0,0)
> > > > > >> >     kernel /vmlinuz-2.6.35 ro
> > > > > >> > root=UUID=686dc496-8814-4c36-8fb7-5ded2916e825 rhgb
> > > > > >> > SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
> > > > > >> > rdblacklist=nouveau init=/sbin/bootchartd
> > > > > >> >     initrd /initramfs-2.6.35.img
> > > > > >> >
> > > > > >> >
> > > > > >> > My boot failure seems to be different than other two reported
> > > > > >> > in the thread "2.6.35-rc6-git6: Reported regressions from 2.6.34"
> > > > > >> > under Bug #16173 and #16228
> > > > > >>
> > > > > >> Will it boot with the "pci=nocrs" option?  If so, please open a
> > > > > >
> > > > > > No, I tried this on a few attempts when I saw it mentioned under
> > > > > > bug #16228.  But it had no effect/benefit.  Sorry, I should have
> > > > > > mentioned this.
> > > > > >
> > > > > >> report at https://bugzilla.kernel.org, mark it a regression, assign
> > > > > >> it to me, and attach the complete dmesg log.  And please respond to
> > > > > >> this thread with a pointer to the bugzilla.
> > > > > >>
> > > > > >> Otherwise, a complete console log should have a clue.  The best
> > > > > >> thing would be a log from a serial console or netconsole, with
> > > > > >> "ignore_loglevel".
> > > > > >
> > > > > > Maybe I will try netconsole tomorrow.  But is Ethernet up when
> > > > > > this boot failure happens?  I think not, since initramfs should
> > > > > > not need networking.
> > > > > >
> > > > > > Should I try building sata driver into kernel?  Oh, I am using
> > > > > > ext3, and fdisk -l shows:
> > > > > 
> > > > > # dracut --add-drivers "sata" ....
> > > > > 
> > > > > or edit /etc/dracut.conf:
> > > > > 
> > > > > add_drivers+=" sata "
> > > > 
> > > > But the kernel used to boot with same identical modules before
> > > > but not after 2.6.34-git4.
> > > >  --------
> > > > 
> > > > Using your suggestion as to where the problem lies, I investigated
> > > > more deeply and found:
> > > > 
> > > > I've now got 2.6.35-rc6-git3 to boot (and almost certainly 2.6.35 final)
> > > > 
> > > > Make oldconfig broke at the transition where boot began failed, ie,
> > > > between 2.6.34-git4 and 2.6.34-git5.   Even though modules are the
> > > > same, boot fails.  If I use gconfig and set CONFIG_SATA_AHCI=y
> > > > instead of CONFIG_SATA_AHCI=m it works, except cannot select =y
> > > > unless CONFIG_ATA changed from m to y.
> > > > 
> > > > So at some point in past, make oldconfig had apparently changed
> > > > CONFIG_SATA_AHCI from y to m and system still booted.  But between
> > > > 2.6.34-git4 and 2.6.34-git5 the ability to boot was lost.
> > > > 
> > > > So make oldconfig is not 100% trustworthy in this case.  I do not
> > > > know if this is a problem that should be fixed.  Ask if you want
> > > > any .config diffs.
> > > > 
> > > > I am going to reboot with 2.6.35 to make sure it boots. Yes!
> > > > 
> > > > I consider this boot problem solved unless someone wants to
> > > > improve "make oldconfig" behavior.
> > > 
> > > It would be good to be able to explain what you are seeing & describing,
> > > so yes, if you can send a .config file that exhibits the problem, I'd
> > > love to look at it.
> > > 
> > > thanks,
> > > ---
> > > ~Randy
> > 
> > 
> > Okay, here is the diff between 2.6.34-git4 and 2.6.34-git5
> > It should be equivalent to make silentoldconfig as I made no
> > changes, just enter to accept defaults.  The git4 boots and
> > git5 does not boot.     (Both based off 2.6.34.1.config)
> 
> Yes, I had just generated this same diff.
> The only config change that could remotely make a difference is:
> > +# CONFIG_SATA_AHCI_PLATFORM is not set
> 
> and I don't see how it could matter.
> 
> > (and attached config-2.6.34-git4.gz, because .config was too
> >  big for mail list last time.)
> 
> Last time being recently?  lkml accepts email sizes (with attachments)
> up to 300 KB, IIRC.

Maybe http://lkml.indiana.edu/hypermail/linux/kernel/1008.0/index.html
throws out large email but the actual lkml does not?  I did not see
it show up; here is header of email that had large (56.48K) .config:

From: 	Donald Parsons
To: 	Randy Dunlap
Cc: 	linux-kernel <linux-kernel@vger.k.o>, Linus Torvalds
Subject: Re: Linux 2.6.35
Date: 	08/01/2010 11:41:31 PM  (this is EDT)
Mailer: Evolution 2.28.3 (2.28.3-1.fc12) 


> > --- config-2.6.34-git4  2010-08-01 19:52:48.000000000 -0400
> > +++ config-2.6.34-git5  2010-08-01 18:10:14.000000000 -0400
> > @@ -1,7 +1,7 @@
> >  #
> >  # Automatically generated make config: don't edit
...deleted most lines...
> > -#
> >  # CONFIG_STAGING is not set
> >  CONFIG_X86_PLATFORM_DEVICES=y
> >  # CONFIG_ACER_WMI is not set
> > 
> > -------------------------------------------
> > 
> > Can possibly duplicate problem if you have a 
> > sata based PC from last few years.
> > 
> > Set  CONFIG_ATA=m
> 
> That's already =m in this config file.
> 
> > and this becomes CONFIG_SATA_AHCI=m  (cannot select=y)
> 
> That's as expected.  CONFIG_ATA value controls CONFIG_SATA_AHCI
> possible values.
> 
> > 
> > Then 2.6.34.[01] (probably 2 also) will boot.
> > Make silentoldconfig with this .config and see
> > that 2.6.35 will not boot.
> 
> So with CONFIG_ATA=m and CONFIG_SATA_AHCI=m, does 2.6.34-git4 boot
> but 2.6.34-git5 fails to boot?

Yes, that is exactly correct.

Don

Re: Linux 2.6.35

[Randy Dunlap]

On Tue, 03 Aug 2010 13:45:45 -0400 Donald Parsons wrote:

> On Tue, 2010-08-03 at 09:40 -0700, Randy Dunlap wrote:
> > On Tue, 03 Aug 2010 12:26:50 -0400 Donald Parsons wrote:
> > 
> > > Resending to all...
> > > On Mon, 2010-08-02 at 21:42 -0700, Randy Dunlap wrote:
> > > > On Mon, 02 Aug 2010 22:31:41 -0400 Donald Parsons wrote:
> > > > 

[snip]

> > > > 
> > > > It would be good to be able to explain what you are seeing & describing,
> > > > so yes, if you can send a .config file that exhibits the problem, I'd
> > > > love to look at it.
> > > > 
> > > > thanks,
> > > > ---
> > > > ~Randy
> > > 
> > > 
> > > Okay, here is the diff between 2.6.34-git4 and 2.6.34-git5
> > > It should be equivalent to make silentoldconfig as I made no
> > > changes, just enter to accept defaults.  The git4 boots and
> > > git5 does not boot.     (Both based off 2.6.34.1.config)
> > 
> > Yes, I had just generated this same diff.
> > The only config change that could remotely make a difference is:
> > > +# CONFIG_SATA_AHCI_PLATFORM is not set
> > 
> > and I don't see how it could matter.
> > 
> > > (and attached config-2.6.34-git4.gz, because .config was too
> > >  big for mail list last time.)
> > 
> > Last time being recently?  lkml accepts email sizes (with attachments)
> > up to 300 KB, IIRC.
> 
> Maybe http://lkml.indiana.edu/hypermail/linux/kernel/1008.0/index.html
> throws out large email but the actual lkml does not?  I did not see

That could be.  I usually use http://marc.info/?l=linux-kernel
or http://lkml.org .

> it show up; here is header of email that had large (56.48K) .config:

I often post configs that are larger than that one.
I also checked my kernel mailbox and see several much larger emails, in
the 200KB/300KB range.

And the vger.kernel.org postmaster wrote on 13-AUG-2007:

"The posting limit is 400K for linux-kernel, netdev, and one
or two of the other lists."

so it could be something other than size that caused it to be dropped,
like html or some taboo word(s).  E.g., see
http://vger.kernel.org/majordomo-info.html#taboo


> >
> From: 	Donald Parsons
> To: 	Randy Dunlap
> Cc: 	linux-kernel <linux-kernel@vger.k.o>, Linus Torvalds
> Subject: Re: Linux 2.6.35
> Date: 	08/01/2010 11:41:31 PM  (this is EDT)
> Mailer: Evolution 2.28.3 (2.28.3-1.fc12) 
> 
> 
> > > --- config-2.6.34-git4  2010-08-01 19:52:48.000000000 -0400
> > > +++ config-2.6.34-git5  2010-08-01 18:10:14.000000000 -0400
> > > @@ -1,7 +1,7 @@
> > >  #
> > >  # Automatically generated make config: don't edit
> ...deleted most lines...
> > > -#
> > >  # CONFIG_STAGING is not set
> > >  CONFIG_X86_PLATFORM_DEVICES=y
> > >  # CONFIG_ACER_WMI is not set
> > > 
> > > -------------------------------------------
> > > 
> > > Can possibly duplicate problem if you have a 
> > > sata based PC from last few years.
> > > 
> > > Set  CONFIG_ATA=m
> > 
> > That's already =m in this config file.
> > 
> > > and this becomes CONFIG_SATA_AHCI=m  (cannot select=y)
> > 
> > That's as expected.  CONFIG_ATA value controls CONFIG_SATA_AHCI
> > possible values.
> > 
> > > 
> > > Then 2.6.34.[01] (probably 2 also) will boot.
> > > Make silentoldconfig with this .config and see
> > > that 2.6.35 will not boot.
> > 
> > So with CONFIG_ATA=m and CONFIG_SATA_AHCI=m, does 2.6.34-git4 boot
> > but 2.6.34-git5 fails to boot?
> 
> Yes, that is exactly correct.


OK, I'll test that on a test machine.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: Linux 2.6.35

[Randy Dunlap]

On Tue, 03 Aug 2010 13:45:45 -0400 Donald Parsons wrote:

> On Tue, 2010-08-03 at 09:40 -0700, Randy Dunlap wrote:
> > On Tue, 03 Aug 2010 12:26:50 -0400 Donald Parsons wrote:
> > 
> > > Resending to all...
> > > On Mon, 2010-08-02 at 21:42 -0700, Randy Dunlap wrote:
> > > > On Mon, 02 Aug 2010 22:31:41 -0400 Donald Parsons wrote:
> > > > 
> > > > > On Mon, 2010-08-02 at 18:08 +0200, Harald Hoyer wrote: 
> > > > > > On Mon, Aug 2, 2010 at 6:21 AM, Donald Parsons <dparsons@brightdsl.net> wrote:
> > > > > > > On Sun, 2010-08-01 at 21:38 -0600, Bjorn Helgaas wrote:
> > > > > > >> On Sunday, August 01, 2010 08:31:02 pm Donald Parsons wrote:
> > > > > > >> > 2.6.35 still fails to boot for me, as first reported here:
> > > > > > >> >  http://lkml.indiana.edu/hypermail/linux/kernel/1007.3/01144.html
> > > > > > >> >
> > > > > > >> > I've manually bisected it down to around May 20 between
> > > > > > >> >   2.6.34-git4 (boots) and 2.6.34-git5 (boot fails)
> > > > > > >> > Also -git[23] boot, and -git8, -rc[126], rc6-git[136] all fail.
> > > > > > >> >
> > > > > > >> > Unfortunately first time I tried was with 2.6.35-rc6 and
> > > > > > >> > it failed to boot.
> > > > > > >> >
> > > > > > >> > Failure when switching from initramfs to real /root?
> > > > > > >> > Removing kernel "quiet" param appears to show several
> > > > > > >> > lines listing:
> > > > > > >> >
> > > > > > >> >   usb drives/hubs? followed by
> > > > > > >> >   dracut switching root (when booting works)
> > > > > > >> >               or
> > > > > > >> >   usb drives/hubs? followed by
> > > > > > >> >         (missing dracut... line)
> > > > > > >> >   No root device found
> > > > > > >> >   Boot has failed, sleeping forever.   (when it does not boot)
> > > > > > >> >
> > > > > > >> > Grub, typical entry:
> > > > > > >> > title Fedora (2.6.35)
> > > > > > >> >     root (hd0,0)
> > > > > > >> >     kernel /vmlinuz-2.6.35 ro
> > > > > > >> > root=UUID=686dc496-8814-4c36-8fb7-5ded2916e825 rhgb
> > > > > > >> > SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
> > > > > > >> > rdblacklist=nouveau init=/sbin/bootchartd
> > > > > > >> >     initrd /initramfs-2.6.35.img
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > My boot failure seems to be different than other two reported
> > > > > > >> > in the thread "2.6.35-rc6-git6: Reported regressions from 2.6.34"
> > > > > > >> > under Bug #16173 and #16228
> > > > > > >>
> > > > > > >> Will it boot with the "pci=nocrs" option?  If so, please open a
> > > > > > >
> > > > > > > No, I tried this on a few attempts when I saw it mentioned under
> > > > > > > bug #16228.  But it had no effect/benefit.  Sorry, I should have
> > > > > > > mentioned this.
> > > > > > >
> > > > > > >> report at https://bugzilla.kernel.org, mark it a regression, assign
> > > > > > >> it to me, and attach the complete dmesg log.  And please respond to
> > > > > > >> this thread with a pointer to the bugzilla.
> > > > > > >>
> > > > > > >> Otherwise, a complete console log should have a clue.  The best
> > > > > > >> thing would be a log from a serial console or netconsole, with
> > > > > > >> "ignore_loglevel".
> > > > > > >
> > > > > > > Maybe I will try netconsole tomorrow.  But is Ethernet up when
> > > > > > > this boot failure happens?  I think not, since initramfs should
> > > > > > > not need networking.
> > > > > > >
> > > > > > > Should I try building sata driver into kernel?  Oh, I am using
> > > > > > > ext3, and fdisk -l shows:
> > > > > > 
> > > > > > # dracut --add-drivers "sata" ....
> > > > > > 
> > > > > > or edit /etc/dracut.conf:
> > > > > > 
> > > > > > add_drivers+=" sata "
> > > > > 
> > > > > But the kernel used to boot with same identical modules before
> > > > > but not after 2.6.34-git4.
> > > > >  --------
> > > > > 
> > > > > Using your suggestion as to where the problem lies, I investigated
> > > > > more deeply and found:
> > > > > 
> > > > > I've now got 2.6.35-rc6-git3 to boot (and almost certainly 2.6.35 final)
> > > > > 
> > > > > Make oldconfig broke at the transition where boot began failed, ie,
> > > > > between 2.6.34-git4 and 2.6.34-git5.   Even though modules are the
> > > > > same, boot fails.  If I use gconfig and set CONFIG_SATA_AHCI=y
> > > > > instead of CONFIG_SATA_AHCI=m it works, except cannot select =y
> > > > > unless CONFIG_ATA changed from m to y.
> > > > > 
> > > > > So at some point in past, make oldconfig had apparently changed
> > > > > CONFIG_SATA_AHCI from y to m and system still booted.  But between
> > > > > 2.6.34-git4 and 2.6.34-git5 the ability to boot was lost.
> > > > > 
> > > > > So make oldconfig is not 100% trustworthy in this case.  I do not
> > > > > know if this is a problem that should be fixed.  Ask if you want
> > > > > any .config diffs.
> > > > > 
> > > > > I am going to reboot with 2.6.35 to make sure it boots. Yes!
> > > > > 
> > > > > I consider this boot problem solved unless someone wants to
> > > > > improve "make oldconfig" behavior.
> > > > 
> > > > It would be good to be able to explain what you are seeing & describing,
> > > > so yes, if you can send a .config file that exhibits the problem, I'd
> > > > love to look at it.
> > > > 
> > > > thanks,
> > > > ---
> > > > ~Randy
> > > 
> > > 
> > > Okay, here is the diff between 2.6.34-git4 and 2.6.34-git5
> > > It should be equivalent to make silentoldconfig as I made no
> > > changes, just enter to accept defaults.  The git4 boots and
> > > git5 does not boot.     (Both based off 2.6.34.1.config)
> > 
> > Yes, I had just generated this same diff.
> > The only config change that could remotely make a difference is:
> > > +# CONFIG_SATA_AHCI_PLATFORM is not set
> > 
> > and I don't see how it could matter.
> > 
> > > (and attached config-2.6.34-git4.gz, because .config was too
> > >  big for mail list last time.)
> > 
> > Last time being recently?  lkml accepts email sizes (with attachments)
> > up to 300 KB, IIRC.
> 
> Maybe http://lkml.indiana.edu/hypermail/linux/kernel/1008.0/index.html
> throws out large email but the actual lkml does not?  I did not see
> it show up; here is header of email that had large (56.48K) .config:
> 
> From: 	Donald Parsons
> To: 	Randy Dunlap
> Cc: 	linux-kernel <linux-kernel@vger.k.o>, Linus Torvalds
> Subject: Re: Linux 2.6.35
> Date: 	08/01/2010 11:41:31 PM  (this is EDT)
> Mailer: Evolution 2.28.3 (2.28.3-1.fc12) 
> 
> 
> > > --- config-2.6.34-git4  2010-08-01 19:52:48.000000000 -0400
> > > +++ config-2.6.34-git5  2010-08-01 18:10:14.000000000 -0400
> > > @@ -1,7 +1,7 @@
> > >  #
> > >  # Automatically generated make config: don't edit
> ...deleted most lines...
> > > -#
> > >  # CONFIG_STAGING is not set
> > >  CONFIG_X86_PLATFORM_DEVICES=y
> > >  # CONFIG_ACER_WMI is not set
> > > 
> > > -------------------------------------------
> > > 
> > > Can possibly duplicate problem if you have a 
> > > sata based PC from last few years.
> > > 
> > > Set  CONFIG_ATA=m
> > 
> > That's already =m in this config file.
> > 
> > > and this becomes CONFIG_SATA_AHCI=m  (cannot select=y)
> > 
> > That's as expected.  CONFIG_ATA value controls CONFIG_SATA_AHCI
> > possible values.
> > 
> > > 
> > > Then 2.6.34.[01] (probably 2 also) will boot.
> > > Make silentoldconfig with this .config and see
> > > that 2.6.35 will not boot.
> > 
> > So with CONFIG_ATA=m and CONFIG_SATA_AHCI=m, does 2.6.34-git4 boot
> > but 2.6.34-git5 fails to boot?
> 
> Yes, that is exactly correct.

OK, I built and booted 2.6.34-git4 and -git5 with your .config file
and only default changes for -git5.

They both booted successfully for me on an f11 box.
I am not using dracut, if that matters.

I don't know what to try next.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: Linux 2.6.35

[Jeff Garzik]

On 08/02/2010 10:31 PM, Donald Parsons wrote:
> Using your suggestion as to where the problem lies, I investigated
> more deeply and found:
>
> I've now got 2.6.35-rc6-git3 to boot (and almost certainly 2.6.35 final)
>
> Make oldconfig broke at the transition where boot began failed, ie,
> between 2.6.34-git4 and 2.6.34-git5.   Even though modules are the
> same, boot fails.  If I use gconfig and set CONFIG_SATA_AHCI=y
> instead of CONFIG_SATA_AHCI=m it works, except cannot select =y
> unless CONFIG_ATA changed from m to y.
>
> So at some point in past, make oldconfig had apparently changed
> CONFIG_SATA_AHCI from y to m and system still booted.  But between
> 2.6.34-git4 and 2.6.34-git5 the ability to boot was lost.
>
> So make oldconfig is not 100% trustworthy in this case.  I do not
> know if this is a problem that should be fixed.  Ask if you want
> any .config diffs.


The modules are not necessarily the same:  "libahci" was introduced in

	commit 365cfa1ed5a36f9bcb9f64c9f0f52155af2e9fef
	Author: Anton Vorontsov <avorontsov@ru.mvista.com>
	Date:   Sun Mar 28 00:22:14 2010 -0400

	    ahci: Move generic code into libahci

so there exists the possibility that the initramfs builder, or whatever 
is being used to load your ATA drivers, missed this dependency.  Modern 
initramfs builders should be able to figure out module dependencies, so 
this /shouldn't/ be an issue...  but it might be.

	Jeff

Linux 2.6.35

[Linus Torvalds]

So I said -rc6 would likely be the last -rc, and nothing happened to
change my mind. I'd always be happier if it had been an even quieter
week, but the appended Shortlog of changes since rc6 doesn't contain
anything earthshaking, and I don't think we'd have been any better off
by another rc, and waiting one more week. So 2.6.35 is out, go check
it out.

This may have been a fairly odd release cycle with my rather strict
-rc rules before -rc3, but on the whole I think I liked it, and it
seems to have worked out ok. I relaxed my extreme stance after getting
back from vacation, so the latter half of the rc series was more
normal. But even then I got the feeling that people were perhaps a bit
more aware of the whole "regression fixes only" model, which is all
good. It's a bit hard to judge, but there are some numbers to back it
up: in the 2.6.34 release, there were 3800 commits after -rc1, but in
the current 35 release cycle we had less than 2000.

Now, admittedly 34 was worse than average in that respect (3800
commits is a _lot_ of work after -rc1), but git history says that at
least going back to 2.6.24, we've never had less than 2000 commits
after -rc1 before now. They tend to be in the 2700-3200 commit range.
So I do think we really did have a lot less churn than usual
post-merge-window. And that's good.

So I'd like to try to repeat the experiment for the next release
cycle, and be pretty hardnosed about taking patches and git pull
requests after the merge window closes.

Talking about the next merge window: Andrew Morton was pretty unhappy
with the stability of linux-next at least a couple of weeks ago. It's
what he bases his -mm trees on, and so an unstable linux-next makes it
hard for Andrew to get his work done. It also makes me worried,
because a lot of people seem to think that "it's been in linux-next
for several months" means that something can and should be merged. And
if linux-next ends up being really flaky, that clearly cannot be the
case.

So guys - please don't treat linux-next as a dumping ground. Things
that go in there should be more or less ready for merging (with an
emphasis on "more"), and we need to keep that tree in working order.
If you're nervous about the stability of your work, you should just
admit that it's not ready to be merged, shouldn't go in the next
release cycle, and shouldn't be in linux-next yet and make life harder
for people like Andrew - or for the other more careful linux-next
submitters.

On a slightly happier note: one thing I do hope we can merge in the
upcoming merge window is Nick Piggin's cool VFS scalability series.
I've been using it on my own machine, and gone through all the commits
(not that I shouldn't go through some of them some more), and am
personally really excited about it. It's seldom we see major
performance improvements in core code that are quite that noticeable,
and Nick's whole RCU pathname lookup in particular just tickles me
pink.

Anything else? I'm sure there's tons of things I should say about what
went into 2.6.35, but as usual there are already better writeups about
what has changed. Things like the kernelnewbies pages etc. So head off
to

  http://kernelnewbies.org/Linux_2_6_35

for some overviews of the things that changed this time around. Or
just download the kernel from the regular places, and give it a test.

                       Linus

---
Adam Jackson (2):
      drm/i915: Make G4X-style PLL search more permissive
      drm/edid: Fix the HDTV hack sync adjustment

Adam Lackorzynski (1):
      x86, i8259: Only register sysdev if we have a real 8259 PIC

Alex Chiang (1):
      ACPI: processor: fix processor_physically_present on UP

Alexey Shvetsov (1):
      wimax/i2400m: Add PID & VID for Intel WiMAX 6250

Andre Osterhues (1):
      ecryptfs: Bugfix for error related to ecryptfs_hash_buckets

Andrea Shepard (1):
      net: Fix corruption of skb csum field in pskb_expand_head() of
net/core/skbuff.c

Andrej Gelenberg (1):
      [CPUFREQ] revert "[CPUFREQ] remove rwsem lock from
CPUFREQ_GOV_STOP call (second call site)"

Andrew Bird (1):
      USB: New PIDs for Qualcomm gobi 2000 (qcserial)

Andy Gospodarek (1):
      ixgbe/igb: catch invalid VF settings

Anton Blanchard (2):
      powerpc/mm: Handle hypervisor pte insert failure in __hash_page_huge
      [SCSI] ibmvscsi: Fix oops when an interrupt is pending during probe

Anton Vorontsov (1):
      edac: mpc85xx: fix coldplug/hotplug module autoloading

Anuj Aggarwal (1):
      regulator: tps6507x: allow driver to use DEFDCDC{2,3}_HIGH register

Arnaldo Carvalho de Melo (1):
      perf annotate: Fix handling of goto labels that are valid hex numbers

Avi Kivity (1):
      KVM: Use kmalloc() instead of vmalloc() for KVM_[GS]ET_MSR

Axel Lin (2):
      ab3100: fix off-by-one value range checking for voltage selector
      wm8350-regulator: fix wm8350_register_regulator error handling

Ben Greear (1):
      net: dev_forward_skb should call nf_reset

Ben Hutchings (1):
      MIPS: Set io_map_base for several PCI bridges lacking it

Benjamin Herrenschmidt (4):
      powerpc/mm: Move around testing of _PAGE_PRESENT in hash code
      powerpc/mm: Fix bugs in huge page hashing
      powerpc/mm: Add some debug output when hash insertion fails
      powerpc: Fix erroneous lmb->memblock conversions

Bob Copeland (1):
      USB: usb-storage: fix initializations of urb fields

Borislav Petkov (1):
      [CPUFREQ] powernow-k8: Limit Pstate transition latency check

Breno Leitao (1):
      s2io: fixing DBG_PRINT() macro

Brian Haley (1):
      ipv6: Don't add routes to ipv6 disabled interfaces.

Bruno Randolf (1):
      MIPS: MTX-1: Fix PCI on the MeshCube and related boards

Catalin Marinas (3):
      ARM: 6271/1: Introduce *_relaxed() I/O accessors
      ARM: 6272/1: Convert L2x0 to use the IO relaxed operations
      ARM: 6273/1: Add barriers to the I/O accessors if ARM_DMA_MEM_BUFFERABLE

Chris Wilson (4):
      drm/i915: Explosion following OOM in do_execbuffer.
      drm/i915: Clear any existing dither mode prior to enabling
spatial dithering
      drm/i915: Use the correct scanout alignment for fbcon.
      drm/i915: Fix panel fitting regression since 734b4157

Christof Schmitt (2):
      [SCSI] zfcp: Do not wait for SBALs on stopped queue
      [SCSI] zfcp: Update status read mempool

Colin Leitner (1):
      USB: ftdi_sio: support for Signalyzer tools based on FTDI chips

Conny Seidel (1):
      perf tools: Fix fallback to cplus_demangle() when bfd_demangle()
is not available

Corey Minyard (1):
      USB: FTDI: Add support for the RT System VX-7 radio programming cable

Dan Carpenter (1):
      nfs: include space for the NUL in root path

Daniel J Blueman (3):
      quiesce EDAC initialisation on desktop/mobile i7
      [CPUFREQ] fix double freeing in error path of pcc-cpufreq
      drm/radeon/kms: fix radeon mid power profile reporting

David Daney (3):
      MIPS: "Fix" useless 'init_vdso successfully' message.
      MIPS: Make init_vdso a subsys_initcall.
      MIPS: Quit using undefined behavior of ADDU in 64-bit atomic operations.

David Howells (3):
      CRED: Fix get_task_cred() and task_state() to not resurrect dead
credentials
      CRED: Fix __task_cred()'s lockdep check and banner comment
      CIFS: Remove __exit mark from cifs_exit_dns_resolver()

David S. Miller (1):
      net: Fix skb_copy_expand() handling of ->csum_start

David VomLehn (1):
      MIPS: PowerTV: Move register setup to before reading registers.

Dennis Jansen (1):
      USB: option: Add support for AMOI Skypephone S2

Dmitry Torokhov (1):
      Input: RX51 keymap - fix recent compile breakage

Eric Miao (3):
      [ARM] pxa/corgi: fix MMC/SD card detection failure
      [ARM] pxa: fix incorrect order of AC97 reset pin configs
      [ARM] pxa: fix incorrect CONFIG_CPU_PXA27x to CONFIG_PXA27x

Eric W. Biederman (4):
      Driver-core: Always create class directories for classses that
support namespaces.
      sysfs: Don't allow the creation of symlinks we can't remove
      sysfs: sysfs_delete_link handle symlinks from untagged to tagged
directories.
      sysfs: allow creating symlinks from untagged to tagged directories

Felipe Balbi (1):
      USB: musb: tusb6010: fix compile error with n8x0_defconfig

Florian Fainelli (1):
      MIPS: BCM63xx: Prevent second enet registration on BCM6338

Frederic Weisbecker (1):
      perf: Fix various display bugs with parent filtering

Gary King (1):
      ARM: 6279/1: highmem: fix SMP preemption bug in kmap_high_l1_vipt

Greg Edwards (1):
      bonding: set device in RLB ARP packet handler

Gui Jianfeng (1):
      perf symbols: Fix directory descriptor leaking

Heiko Carstens (1):
      [S390] Fix IRQ tracing in case of PER

Herbert Xu (1):
      macvtap: Limit packet queue length

Hugh Dickins (1):
      mm: fix ia64 crash when gcore reads gate area

Jason Baron (1):
      dynamic debug: move ddebug_remove_module() down into free_module()

Jason Wessel (1):
      x86,kgdb: Fix hw breakpoint regression

Jeremy Kerr (5):
      ARM: 6258/1: arm/h720x: fix debug macro compilation failure
      ARM: 6259/1: arm/ns9xxx: fix debug macro compilation failure
      ARM: 6260/1: arm/plat-spear: fix debug macro compilation failure
      ARM: 6261/1: arm/shark: fix debug macro compilation failure
      ARM: 6262/1: arm/clps711x: fix debug macro compilation failure

Jesse Barnes (8):
      drm/i915: handle shared framebuffers when flipping
      drm/i915: add PANEL_UNLOCK_REGS definition
      drm/i915: make sure eDP panel is turned on
      drm/i915: disable FBC when more than one pipe is active
      drm/i915: don't free non-existent compressed llb on ILK+
      drm/i915: fix deadlock in fb teardown
      drm/i915: add pipe A force quirks to i915 driver
      drm/i915: make sure we shut off the panel in eDP configs

John W. Linville (1):
      wireless: use netif_rx_ni in ieee80211_send_layer2_update

Jon Povey (1):
      gpio: fix spurious printk when freeing a gpio

Julia Lawall (1):
      SA1111: Eliminate use after free

KOSAKI Motohiro (1):
      ACPI: fix unused function warning

Kumar Gala (1):
      powerpc/kexec: Fix boundary case for book-e kexec memory limits

Latchesar Ionkov (1):
      9p: Pass the correct end of buffer to p9stat_read

Len Brown (3):
      ACPI: handle systems which asynchoronously enable ACPI mode
      ACPI: skip checking BM_STS if the BIOS doesn't ask for it
      ACPI: create "processor.bm_check_disable" boot param

Linus Torvalds (1):
      Linux 2.6.35

Magnus Damm (1):
      ARM: 6270/1: clean files in arch/arm/boot/compressed/

Marek Vasut (2):
      [ARM] pxa: cpufreq-pxa2xx: fix DRI recomputation routine
      [ARM] pxa: fix frequency scaling for pcmcia/pxa2xx_base

Martin Schwidefsky (1):
      [S390] etr: fix clock synchronization race

Matthew Garrett (2):
      [CPUFREQ] pcc driver should check for pcch method before calling _OSC
      [CPUFREQ] Fix PCC driver error path

Michael S. Tsirkin (2):
      tun: avoid BUG, dump packet on GSO errors
      virtio: fix oops on OOM

Michal Marek (1):
      kbuild: Fix make rpm

Michał Górny (1):
      kbuild: Make the setlocalversion script POSIX-compliant

Ming Lei (1):
      ath9k: fix dma direction for map/unmap in ath_rx_tasklet

Nik A. Melchior (1):
      ACPI video: fix string mismatch for Sony SR290 laptop

Oliver Neukum (2):
      USB: sisusbvga: Fix for USB 3.0
      USB: add quirk for Broadcom BT dongle

Ondrej Zary (2):
      cyber2000fb: fix machine hang on module load
      cyber2000fb: fix console in truecolor modes

Paul Mortier (1):
      USB: adds Artisman USB dongle to list of quirky devices

Peter Huewe (2):
      ds2782_battery: Rename get_current to fix build failure / name conflict
      serial: fix rs485 for atmel_serial on avr32

Peter Zijlstra (1):
      perf, powerpc: Use perf_sample_data_init() for the FSL code

Przemo Firszt (1):
      USB: Expose vendor-specific ACM channel on Nokia 5230

Rabin Vincent (1):
      ARM: 6275/1: ux500: don't use writeb() in uncompress.h

Rafael J. Wysocki (1):
      ACPI / Sleep: Allow the NVS saving to be skipped during suspend to RAM

Rajiv Andrade (1):
      tpm_tis: fix subsequent suspend failures

Ralf Baechle (7):
      VIDEO. gbefb: Fix section mismatches.
      NET: declance: Fix section mismatches
      VIDEO: PMAG-BA: Fix section mismatch
      VIDEO: PMAGB-B: Fix section mismatch
      VIDEO: Au1100fb: Fix section mismatch
      SOUND: Au1000: Fix section mismatch
      MIPS: N32: Define getdents64.

Robert P. J. Day (1):
      ceph: Correct obvious typo of Kconfig variable "CRYPTO_AES"

Rudolf Marek (1):
      drivers/rtc/rtc-rx8581.c: fix setdatetime

Russell King (3):
      ARM: Fix csum_partial_copy_from_user()
      ARM: Add barriers to io{read,write}{8,16,32} accessors as well
      ARM: Fix Versatile/Realview/VExpress MMC card detection sense

Sage Weil (5):
      ceph: avoid dcache readdir for snapdir
      ceph: fix d_release dop for snapdir, snapped dentries
      ceph: fix pg_mapping leak on pg_temp updates
      ceph: fix leak of dentry in ceph_init_dentry() error path
      ceph: fix dentry lease release

Sam Ravnborg (2):
      tracing: Properly align linker defined symbols
      vmlinux.lds: fix .data..init_task output section (fix popwerpc boot)

Sarah Sharp (4):
      USB: xHCI: Fix another bug in link TRB activation change.
      USB: Fix USB3.0 Port Speed Downgrade after port reset
      USB: xhci: Set EP0 dequeue ptr after reset of configured device.
      USB: xhci: Set Mult field in endpoint context correctly.

Sekhar Nori (1):
      davinci: da850/omap-l138 evm: account for DEFDCDC{2,3} being tied high

Stefano Stabellini (1):
      x86: Do not try to disable hpet if it hasn't been initialized before

Stephen Boyd (1):
      nconfig: Fix segfault when help contains special characters

Steven Whitehouse (1):
      GFS2: Use kmalloc when possible for ->readdir()

Swen Schillig (1):
      [SCSI] zfcp: Fix check whether unchained ct_els is possible

Takashi Iwai (4):
      ALSA: hda - Fix pin-detection of Nvidia HDMI
      ALSA: hda - Don't register beep input device when no beep is available
      ALSA: hda - Assume PC-beep as default for Realtek
      ALSA: hda - Add a PC-beep workaround for ASUS P5-V

Thomas Bächler (1):
      gpu/drm/i915: Add a blacklist to omit modeset on LID open

Tim Gardner (1):
      agp/intel: Use the correct mask to detect i830 aperture size.

Trond Myklebust (3):
      NFS: kswapd must not block in nfs_release_page
      NFS: Ensure that writepage respects the nonblock flag
      NFS: Fix a typo in include/linux/nfs_fs.h

Uwe Kleine-König (2):
      ARM: 6263/1: ns9xxx: fix FTBFS for zImage
      ARM: 6265/1: kirkwood: move qnap_tsx1x_register_flash() to .init.text

Vladimir Zapolskiy (1):
      USB: s3c2410_udc: be aware of connected gadget driver

Vladislav Zolotarov (3):
      bnx2x: Protect a SM state change
      bnx2x: Protect statistics ramrod and sequence number
      bnx2x: Advance a module version

Wayne Boyer (1):
      [SCSI] ipr: fix resource path display and formatting

Wim Van Sebroeck (1):
      watchdog: update MAINTAINERS entry

Wolfgang Grandegger (1):
      MIPS: Alchemy: Define eth platform devices in the correct order

Xiao Guangrong (1):
      KVM: MMU: fix conflict access permissions in direct sp

Xiaotian Feng (1):
      [CPUFREQ] fix memory leak in cpufreq_add_dev

Yehuda Sadeh (1):
      ceph: use complete_all and wake_up_all

Zhang Rui (1):
      ACPI battery: don't invoke power_supply_changed twice when
battery is hot-added

august huber (1):
      USB: Add PID for Sierra 250U to drivers/usb/serial/sierra.c

pieterg (1):
      [ARM] pxa/colibri-pxa300: fix AC97 init

stephen hemminger (1):
      net sched: fix race in mirred device removal

wanzongshun (2):
      ARM: 6230/1: fix nuc900 touchscreen clk definition bug
      ARM: 6233/1: Delete a wrong redundant right parenthesis

Ömer Sezgin Ugurlu (1):
      USB: option: add support for 1da5:4518

Re: Linux 2.6.35

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 921 bytes --]

Hi all,

On Sun, 1 Aug 2010 16:52:42 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> On a slightly happier note: one thing I do hope we can merge in the
> upcoming merge window is Nick Piggin's cool VFS scalability series.
> I've been using it on my own machine, and gone through all the commits
> (not that I shouldn't go through some of them some more), and am
> personally really excited about it. It's seldom we see major
> performance improvements in core code that are quite that noticeable,
> and Nick's whole RCU pathname lookup in particular just tickles me
> pink.

To that end, Nick, can you please submit that tree for inclusion in
linux-next in case there are some interactions with some of the other
stuff there?  (or send it all to Al, instead (or both), I guess.)

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: Linux 2.6.35

[Nick Piggin]

On Mon, Aug 02, 2010 at 10:32:04AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> On Sun, 1 Aug 2010 16:52:42 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
> >
> > On a slightly happier note: one thing I do hope we can merge in the
> > upcoming merge window is Nick Piggin's cool VFS scalability series.
> > I've been using it on my own machine, and gone through all the commits
> > (not that I shouldn't go through some of them some more), and am
> > personally really excited about it. It's seldom we see major
> > performance improvements in core code that are quite that noticeable,
> > and Nick's whole RCU pathname lookup in particular just tickles me
> > pink.
> 
> To that end, Nick, can you please submit that tree for inclusion in
> linux-next in case there are some interactions with some of the other
> stuff there?  (or send it all to Al, instead (or both), I guess.)

Hi Stephen,

I will work something out with Al and try to have something in
linux-next ASAP.

Re: Linux 2.6.35

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 296 bytes --]

Hi Nick,

On Mon, 2 Aug 2010 18:14:22 +1000 Nick Piggin <npiggin@suse.de> wrote:
>
> I will work something out with Al and try to have something in
> linux-next ASAP.

OK, great.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: Linux 2.6.35

[Dave Chinner]

On Sun, Aug 01, 2010 at 04:52:42PM -0700, Linus Torvalds wrote:
> On a slightly happier note: one thing I do hope we can merge in the
> upcoming merge window is Nick Piggin's cool VFS scalability series.
> I've been using it on my own machine, and gone through all the commits
> (not that I shouldn't go through some of them some more), and am
> personally really excited about it. It's seldom we see major
> performance improvements in core code that are quite that noticeable,
> and Nick's whole RCU pathname lookup in particular just tickles me
> pink.

There hasn't been nearly enough review or testing of this patch
series yet.  Before a merge, it needs to be split up in smaller,
more digestable chunks for more comprehensive review, regression
testing and behavioural analysis.

There's probably only a handful of people who have done any testing
on the patchset so far, and given the widespread changes it needs a
lot more testing than this before we should consider merging any of
it.

I really want to see this move forward too, but it changes lots of
critical infrastructure in subtle ways and so, IMO, this is not
a patchset we should be gung-ho about.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: Linux 2.6.35

[Linus Torvalds]

On Sun, Aug 1, 2010 at 7:33 PM, Dave Chinner <david@fromorbit.com> wrote:
>
> There hasn't been nearly enough review or testing of this patch
> series yet.  Before a merge, it needs to be split up in smaller,
> more digestable chunks for more comprehensive review, regression
> testing and behavioural analysis.

I dunno. We merge _way_ scarier things in the VM and the block layer,
for much less actual upside, and with less review.

The RCU pathname lookup has some rather impressive performance
upsides, and I agree that it would be good to get a lot of review and
testing, but the latter isn't going to happen without it being
mainlined, and the former is sadly lacking. The person I'd like most
to review it is Al, but anybody in the filesystem world should
basically see it as a #1 priority, because unlike all the masturbatory
patches like xstat() that add new functionality that nobody will
likely ever use, Nick's patchseries improves on the thing that
everybody uses heavily every day without even thinking about it.

Is it tough to review? Yes. It's core code, not just some random
addition that adds a new feature and doesn't impact any old code. But
that's also the thing that makes it meaningful, and makes me think it
should get merged _much_ more eagerly than most code we ever see.

                           Linus

Re: Linux 2.6.35

[Dave Chinner]

On Sun, Aug 01, 2010 at 07:50:02PM -0700, Linus Torvalds wrote:
> On Sun, Aug 1, 2010 at 7:33 PM, Dave Chinner <david@fromorbit.com> wrote:
> >
> > There hasn't been nearly enough review or testing of this patch
> > series yet.  Before a merge, it needs to be split up in smaller,
> > more digestable chunks for more comprehensive review, regression
> > testing and behavioural analysis.
> 
> I dunno. We merge _way_ scarier things in the VM and the block layer,
> for much less actual upside, and with less review.

Scary stuff outside of direct VFS/FS interfaces is generally hidden
from me by my +6 Blinkers of Blissful Ignorance. I make the
assumption that the experts involved know the risks and have weighed
them up appropriately. ;)

> The RCU pathname lookup has some rather impressive performance
> upsides, and I agree that it would be good to get a lot of review and
> testing, but the latter isn't going to happen without it being
> mainlined, and the former is sadly lacking. The person I'd like most
> to review it is Al,

Most definitely.

> but anybody in the filesystem world should
> basically see it as a #1 priority,

Agreed - I've actually looked at every patch, commented on some
of the more questionable things, got quoted by LWN for saying that
it "fell off the locking cliff", have run benchmarks on it and sent
patches fixing bugs back to Nick.

It's just really hard to digest it all in one lump and core VFS
changes on this scale scare me....

> because unlike all the masturbatory
> patches like xstat() that add new functionality that nobody will
> likely ever use, Nick's patchseries improves on the thing that
> everybody uses heavily every day without even thinking about it.
> 
> Is it tough to review? Yes. It's core code, not just some random
> addition that adds a new feature and doesn't impact any old code. But
> that's also the thing that makes it meaningful, and makes me think it
> should get merged _much_ more eagerly than most code we ever see.

I agree with you for the pure locking changes.

But for the bits that change writeback, LRU ordering and reclaim
calculations the benefits are not quite so obvious, nor is the
correctness of the code/behaviour quite so provably correct.  Maybe
I'm being a bit too paranoid, but generally it pays to be a bit
conservative as a filesystem developer because the cost of screwing
up can be pretty high...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: Linux 2.6.35

[Nick Piggin]

On Mon, Aug 02, 2010 at 03:58:34PM +1000, Dave Chinner wrote:
> On Sun, Aug 01, 2010 at 07:50:02PM -0700, Linus Torvalds wrote:
> > On Sun, Aug 1, 2010 at 7:33 PM, Dave Chinner <david@fromorbit.com> wrote:
> > >
> > > There hasn't been nearly enough review or testing of this patch
> > > series yet.  Before a merge, it needs to be split up in smaller,
> > > more digestable chunks for more comprehensive review, regression
> > > testing and behavioural analysis.

BTW. it has in fact had quite a bit of testing in earlier form in the
-rt tree for a long time, and several fixes come from there. And good
performance results there too.


> > I dunno. We merge _way_ scarier things in the VM and the block layer,
> > for much less actual upside, and with less review.
> 
> Scary stuff outside of direct VFS/FS interfaces is generally hidden
> from me by my +6 Blinkers of Blissful Ignorance. I make the
> assumption that the experts involved know the risks and have weighed
> them up appropriately. ;)
> 
> > The RCU pathname lookup has some rather impressive performance
> > upsides, and I agree that it would be good to get a lot of review and
> > testing, but the latter isn't going to happen without it being
> > mainlined, and the former is sadly lacking. The person I'd like most
> > to review it is Al,
> 
> Most definitely.

I hate to say but I would like to see it mature for another release. It
should also clash a bit with Al's recent inode work that he'll want to
push.

What I can do is send some of the ground work patches this time around,
put the tree into linux-next, and put reviewers on notice.

I think it is all conceptually sound, but it will inevitably have some
bugs left to shake out, and things to be fixed on the review side. I
don't anticipate a problem that could not be fixed in the release cycle,
but I think aiming for post 2.6.36 is a bit fairer for vfs guys,
honestly. LSF is next week too, so most of them will be busy with travel
and such. But I do hope to discuss the vfs-scale patches there.


> > but anybody in the filesystem world should
> > basically see it as a #1 priority,
> 
> Agreed - I've actually looked at every patch, commented on some
> of the more questionable things, got quoted by LWN for saying that
> it "fell off the locking cliff", have run benchmarks on it and sent
> patches fixing bugs back to Nick.
> 
> It's just really hard to digest it all in one lump and core VFS
> changes on this scale scare me....

For filesystems developers, the dcache and inode locking changes
should be more or less just following simple steps as shown in the
patch series. If they're not abusing dcache_lock (and most except
autofs4 are not), then it should not be a big deal.

There are a couple of locking constraints changed at the API level,
but I didn't run into any problems there yet. It should be all
documented in Documentation/filesystems/* although I need to run a
few more passes over the series to ensure I caught everything.


> > because unlike all the masturbatory
> > patches like xstat() that add new functionality that nobody will
> > likely ever use, Nick's patchseries improves on the thing that
> > everybody uses heavily every day without even thinking about it.
> > 
> > Is it tough to review? Yes. It's core code, not just some random
> > addition that adds a new feature and doesn't impact any old code. But
> > that's also the thing that makes it meaningful, and makes me think it
> > should get merged _much_ more eagerly than most code we ever see.
> 
> I agree with you for the pure locking changes.
> 
> But for the bits that change writeback, LRU ordering and reclaim
> calculations the benefits are not quite so obvious, nor is the
> correctness of the code/behaviour quite so provably correct.  Maybe
> I'm being a bit too paranoid, but generally it pays to be a bit
> conservative as a filesystem developer because the cost of screwing
> up can be pretty high...

Writeback shouldn't be changed. LRU ordering is changed for 2
reasons. Firstly, to make things per-zone instead of global. This
basically fits our whole reclaim model much better, although it
will inevitably cause some random little changes but I think it
is agreed this is a good thing (memory shortage in one zone or
node does not require global shrinkings, NUMA level parallelism
of reclaim.)

The other thing is converting the last few dcache refcounting, and
all of inode refcounting over to this "lazy LRU" model. This can
have a bigger impact, but it really reduces locking on the per-zone
lists, so it definitely helps speed and scalability of non-reclaim
fastpaths. I'm up for changing this if numbers show it hurts, it
would be rather easy to do, but in comparison to the overall
patchset, it would rate as a minor tweak :)

Re: Linux 2.6.35

[Christoph Hellwig]

On Mon, Aug 02, 2010 at 05:55:37PM +1000, Nick Piggin wrote:
> I hate to say but I would like to see it mature for another release. It
> should also clash a bit with Al's recent inode work that he'll want to
> push.
> 
> What I can do is send some of the ground work patches this time around,
> put the tree into linux-next, and put reviewers on notice.
> 
> I think it is all conceptually sound, but it will inevitably have some
> bugs left to shake out, and things to be fixed on the review side. I
> don't anticipate a problem that could not be fixed in the release cycle,
> but I think aiming for post 2.6.36 is a bit fairer for vfs guys,
> honestly. LSF is next week too, so most of them will be busy with travel
> and such. But I do hope to discuss the vfs-scale patches there.

What I'm most concerned bit merging everything in one go.  It's a huge
series and I'd rather see it start going in in batches over multiple
kernel releases.

Things like the fs_struct spinlock and some other preparatory patches
should be ver easily to do for 2.6.36.  Scaling the files and vfsmount
locks should also be easily doable, but we need to sort out the struct
file growth in the later.  We really can't grow struct file by two
pointers as that would have devasting effects on various workloads.

What follows after that is the dcache_lock scaling which to seems the
most immature bit of the series, and the one that showed by far the
most problems in -RT.  I'm very much dead set against merging that in
.36.  I'd much rather see the inode_lock scaling or the lockless path
walk going in before, but I haven't checked how complicated the
reordering would be.  The lockless path walk also is only rather
theoretically useful until we do ACL checks lockless as we're having
ACLs enabled pretty much everywhere at least in the distros.

The per-zone shrinkers are another thing that's not directly related,
I think they need a lot more discussion with the VM folks, and
integrating with Dave's work in that area.

Re: Linux 2.6.35

[KOSAKI Motohiro]

> The per-zone shrinkers are another thing that's not directly related,
> I think they need a lot more discussion with the VM folks, and
> integrating with Dave's work in that area.

per-zone shrinkers don't cause so much impact to VM design except zone
reclaim feature. So, if FS folks think it's ok, I'm not against this at all.

btw, however, I haven't review such patch series in the detail yet. so
perhaps I might post some bug fix later.

Re: Linux 2.6.35

[Christoph Hellwig]

On Mon, Aug 02, 2010 at 04:24:28AM -0400, Christoph Hellwig wrote:
> .36.  I'd much rather see the inode_lock scaling or the lockless path
> walk going in before, but I haven't checked how complicated the
> reordering would be.  The lockless path walk also is only rather
> theoretically useful until we do ACL checks lockless as we're having
> ACLs enabled pretty much everywhere at least in the distros.

>From a quick look it seems like the inode_lock splitup can easily
be moved forward, and it would help us with doing some work on the
writeback side.  The problem is that it would need rebasing ontop
of both the vfs and writeback (aka block) trees.

Re: Linux 2.6.35

[Nick Piggin]

On Mon, Aug 02, 2010 at 05:05:42AM -0400, Christoph Hellwig wrote:
> On Mon, Aug 02, 2010 at 04:24:28AM -0400, Christoph Hellwig wrote:
> > .36.  I'd much rather see the inode_lock scaling or the lockless path
> > walk going in before, but I haven't checked how complicated the
> > reordering would be.  The lockless path walk also is only rather
> > theoretically useful until we do ACL checks lockless as we're having
> > ACLs enabled pretty much everywhere at least in the distros.
> 
> >From a quick look it seems like the inode_lock splitup can easily
> be moved forward, and it would help us with doing some work on the
> writeback side.  The problem is that it would need rebasing ontop
> of both the vfs and writeback (aka block) trees.

inode_lock splitup is much simpler than dcache_lock, yes.

And I have to rebase it on the work currently queued for 2.6.35
anyway, so that's no problem. I can easily put it in front of
dcache_lock patches in the series (as I said, I've kept everything
independent and well split up).

I do want opinions on how to do the big-picture merge, though,
before I start moving things around. And obviously reviewing
each of the parts is more important at this point than exact
way to order the thing.

But even the inode_lock patches I am wary of merging in 2.6.36
without having much review or any linux-next / vfs-tree exposure.

Re: Linux 2.6.35

[Nick Piggin]

On Mon, Aug 02, 2010 at 04:24:28AM -0400, Christoph Hellwig wrote:
> On Mon, Aug 02, 2010 at 05:55:37PM +1000, Nick Piggin wrote:
> > I hate to say but I would like to see it mature for another release. It
> > should also clash a bit with Al's recent inode work that he'll want to
> > push.
> > 
> > What I can do is send some of the ground work patches this time around,
> > put the tree into linux-next, and put reviewers on notice.
> > 
> > I think it is all conceptually sound, but it will inevitably have some
> > bugs left to shake out, and things to be fixed on the review side. I
> > don't anticipate a problem that could not be fixed in the release cycle,
> > but I think aiming for post 2.6.36 is a bit fairer for vfs guys,
> > honestly. LSF is next week too, so most of them will be busy with travel
> > and such. But I do hope to discuss the vfs-scale patches there.
> 
> What I'm most concerned bit merging everything in one go.  It's a huge
> series and I'd rather see it start going in in batches over multiple
> kernel releases.

One problem is that to win much benefit, several different aspects
must be scaled. If not, then you end up with more locks *and* still
have bouncing global cachelines. And filesystems will go through
multiple releases where locking changes are in flux. This is what
I'm concerned about.

I definitely have tried to keep everything as conceptually seperate
small chunks. But there is a real big-picture aspect that is required
to review it.

For example, you asked for just the locking split-up without any of
the per-hash-locks and per-cpu locks etc. That's fine for review, but
you cannot merge it because then you end up with N bouncing global
locks instead of 1. It also tends to be much uglier than a final
outcome because I have not applied any transformations to improve lock
orderings and reduce trylocking etc.


> Things like the fs_struct spinlock and some other preparatory patches
> should be ver easily to do for 2.6.36.  Scaling the files and vfsmount
> locks should also be easily doable, but we need to sort out the struct
> file growth in the later.  We really can't grow struct file by two
> pointers as that would have devasting effects on various workloads.

Strictly, it is a filesystem corruption bug-fix for the tty layer
and nothing to do with tty scaling patches.

I don't have the patience at the moment to sort through tty layer
crap, but whoever is maintaining that should. I could possibly come
back and look at it some point, but given your half-working patch
as a guide, I think someone who knows the code can fix it.


> What follows after that is the dcache_lock scaling which to seems the
> most immature bit of the series, and the one that showed by far the
> most problems in -RT.  I'm very much dead set against merging that in
> .36.

That's a fair point, I agree with. It needs most review.


>  I'd much rather see the inode_lock scaling or the lockless path
> walk going in before, but I haven't checked how complicated the
> reordering would be.

I would much prefer not to re-order it before either of inode or
dcache scaling patches. It would introduce a lot of churn and
locking is significantly changed.

It probably should be possible, although we would still get path
walk contention on dcache_lock, vfsmount_lock, and requires inode-RCU
(making inodes more expensive without being offset by any benefits of
inode scaling), and requires changes to filesystem dcache and inode
APIs.

I could work on re-ordering it certainly, but only if it is decided
that we definitely don't want dcache-scale or inode-scale patch sets
in the forseeable future. I think we definitely do want them, so I
find it hard to justify a big reordering.


>  The lockless path walk also is only rather
> theoretically useful until we do ACL checks lockless as we're having
> ACLs enabled pretty much everywhere at least in the distros.

True, it needs a last bit of work for permission checking. The 
conceptual idea and the bulk of the code I think is ready to review
though. ACLs should be just more of the same.


> The per-zone shrinkers are another thing that's not directly related,
> I think they need a lot more discussion with the VM folks, and
> integrating with Dave's work in that area.

Well I'm a VM folk :) Conceptually, there is no problems for MM
here. This is really the right way to drive reclaim from the MM
perspective (ie. per-zone). Of course I will work with Dave and
take suggestions on implementation.

It is directly related in that it is required to remove global lock and
global list scanning from vfs reclaim, which is something that we've
known and wanted for a long time.

On one hand, you might say I'm going overboard, but on another hand,
vfs really sucks on NUMA and SMP right now and it's only going to
get worse for "normal" (ie. not HPC) people.

Re: Linux 2.6.35

[Andi Kleen]

Dave Chinner <david@fromorbit.com> writes:

> On Sun, Aug 01, 2010 at 04:52:42PM -0700, Linus Torvalds wrote:
>> On a slightly happier note: one thing I do hope we can merge in the
>> upcoming merge window is Nick Piggin's cool VFS scalability series.
>> I've been using it on my own machine, and gone through all the commits
>> (not that I shouldn't go through some of them some more), and am
>> personally really excited about it. It's seldom we see major
>> performance improvements in core code that are quite that noticeable,
>> and Nick's whole RCU pathname lookup in particular just tickles me
>> pink.
>
> There hasn't been nearly enough review or testing of this patch
> series yet.  Before a merge, it needs to be split up in smaller,
> more digestable chunks for more comprehensive review, regression
> testing and behavioural analysis.

We started some testing of the VFS series on larger systems and so
far it looks all very good and the performance improvements are impressive
(but of course new bottlenecks are being exposed then)

The only snag found so far was that an ACL enabled file system
disables all the nice path walk improvements, so right now you
need to remount with noacl. I'm hoping this can be fixed
before a mainline release, otherwise I suspect it would disable
the improvements for lots of people (common distributions default
to acl on)

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

Re: Linux 2.6.35

[Nick Piggin]

On Tue, Aug 03, 2010 at 10:18:30AM +0200, Andi Kleen wrote:
> Dave Chinner <david@fromorbit.com> writes:
> 
> > On Sun, Aug 01, 2010 at 04:52:42PM -0700, Linus Torvalds wrote:
> >> On a slightly happier note: one thing I do hope we can merge in the
> >> upcoming merge window is Nick Piggin's cool VFS scalability series.
> >> I've been using it on my own machine, and gone through all the commits
> >> (not that I shouldn't go through some of them some more), and am
> >> personally really excited about it. It's seldom we see major
> >> performance improvements in core code that are quite that noticeable,
> >> and Nick's whole RCU pathname lookup in particular just tickles me
> >> pink.
> >
> > There hasn't been nearly enough review or testing of this patch
> > series yet.  Before a merge, it needs to be split up in smaller,
> > more digestable chunks for more comprehensive review, regression
> > testing and behavioural analysis.
> 
> We started some testing of the VFS series on larger systems and so
> far it looks all very good and the performance improvements are impressive
> (but of course new bottlenecks are being exposed then)
> 
> The only snag found so far was that an ACL enabled file system
> disables all the nice path walk improvements, so right now you
> need to remount with noacl. I'm hoping this can be fixed
> before a mainline release, otherwise I suspect it would disable
> the improvements for lots of people (common distributions default
> to acl on)

OK, vfs-scale-working branch now has commits to enable rcu-walk aware
d_revalidate, permission, and check_acl in the filesystems, and
implements a basic rcu-walk aware scheme for generic/posix acls and
implements that for tmpfs, ext2, btrfs. It just drops out of rcu-walk
if there is an ACL on a directory, or if it is not cached. I think
that's enough to be production ready now. Pushing rcu-walk awareness
down into acl checking code would not be hard.

I was under the impression that ACLs on directories are not that common,
so maybe this is as far as we need to go for now anyway.

It does need more commenting of the new methods and explaining how they
can and can't be used by filesystems. The tree is also getting messy
with incremental changes -- I'm avoiding rebasing it so people following
it can see response to reviews and issues that arise. Obviously it will
all get cleaned up and rebased properly onto a new branch before
anything is merged.

Re: Linux 2.6.35

[Andi Kleen]

On Tue, Aug 03, 2010 at 07:28:23PM +1000, Nick Piggin wrote:
> OK, vfs-scale-working branch now has commits to enable rcu-walk aware
> d_revalidate, permission, and check_acl in the filesystems, and
> implements a basic rcu-walk aware scheme for generic/posix acls and

Cool. I was just looking at that.

> I was under the impression that ACLs on directories are not that common,
> so maybe this is as far as we need to go for now anyway.

Yes it shouldn't be common normally. I think the common case for distros
is just a few ACLs in /dev. Of course you never know for 
specific end user workloads.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

Re: Linux 2.6.35

[Henrique de Moraes Holschuh]

On Tue, 03 Aug 2010, Nick Piggin wrote:
> I was under the impression that ACLs on directories are not that common,
> so maybe this is as far as we need to go for now anyway.

They are quite common on fileserver data areas, at least on the places where
I worked at.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh