Linux 2.6.35
in [Kernel]
|
Prev: Fix /proc/softirqs file formatting
Next: [ANNOUNCE] mtdev v1.0.8 -- Multitouch Protocol Translation Library
From: Frédéric L. W. Meunier on 2 Aug 2010 18:10 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Frédéric L. W. Meunier on 2 Aug 2010 18:40 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.
From: Donald Parsons on 2 Aug 2010 22:40 On Mon, 2010-08-02 at 18:08 +0200, Harald Hoyer wrote: > On Mon, Aug 2, 2010 at 6:21 AM, Donald Parsons <dparsons(a)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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Randy Dunlap on 3 Aug 2010 00:50 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(a)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 *** -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andi Kleen on 3 Aug 2010 04:20
Dave Chinner <david(a)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(a)linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |