Linux 2.6.35
in [Kernel]
|
Prev: Fix /proc/softirqs file formatting
Next: [ANNOUNCE] mtdev v1.0.8 -- Multitouch Protocol Translation Library
From: Nick Piggin on 2 Aug 2010 07:10 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. -- 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: Bjorn Helgaas on 2 Aug 2010 09:50 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(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: Harald Hoyer on 2 Aug 2010 12:10 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 " -- 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: Harald Hoyer on 2 Aug 2010 12:10 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(a)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(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/ -- 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: Donald Parsons on 2 Aug 2010 14:40
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 -- 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/ |