kexec boot regression
in [Kernel]
|
Prev: [mmotm][PATCH 4/5] mm : add lowmem detection logic
Next: move eject code from zd1211rw to usb-storage
From: Jens Axboe on 15 Dec 2009 07:00 Hi, I have this big box that takes forever to boot, so I use kexec to boot into new kernels. Works fine, but some time past 2.6.32 it stopped working. Instead of wasting brain cycles on finding out why, I handed the problem to my trusty regression friend - git bisect. This is what it found (sorry Yinghai it's you again, you owe me a beer for hours of 2.6.32-git bisecting ;-) 99935a7a59eaca0292c1a5880e10bae03f4a5e3d is the first bad commit commit 99935a7a59eaca0292c1a5880e10bae03f4a5e3d Author: Yinghai Lu <yinghai(a)kernel.org> Date: Sun Oct 4 21:54:24 2009 -0700 x86/PCI: read root resources from IOH on Intel For intel systems with multi IOH, we should read peer root resources directly from PCI config space, and don't trust _CRS. I could not revert this single commit, as a further commit made other changes. So I reverted 67f241f4 first and then 99935a7a. I confirmed that this kernel then works fine. With current -git, I get tons and tons of: [ 16.841724] pci 0000:00:01.0: BAR 7: no parent found for bridge [io 0x6000-0x6fff] [ 16.850368] pci 0000:00:01.0: BAR 7: can't allocate [io 0x6000-0x6fff] [ 16.857821] pci 0000:00:01.0: BAR 8: no parent found for bridge [mem 0x9bc00000-0x9bcfffff] [ 16.867238] pci 0000:00:01.0: BAR 8: can't allocate [mem 0x9bc00000-0x9bcfffff] [ 16.875492] pci 0000:00:02.0: BAR 7: no parent found for bridge [io 0x5000-0x5fff] [ 16.884137] pci 0000:00:02.0: BAR 7: can't allocate [io 0x5000-0x5fff] [ 16.891591] pci 0000:00:02.0: BAR 8: no parent found for bridge [mem 0x9bb00000-0x9bbfffff] [ 16.901010] pci 0000:00:02.0: BAR 8: can't allocate [mem 0x9bb00000-0x9bbfffff] [ 16.909264] pci 0000:00:03.0: BAR 7: no parent found for bridge [io 0x4000-0x4fff] [ 16.917908] pci 0000:00:03.0: BAR 7: can't allocate [io 0x4000-0x4fff] [...] I can provide a full log if needed. -- Jens Axboe -- 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: Yinghai Lu on 15 Dec 2009 07:10 Jens Axboe wrote: > Hi, > > I have this big box that takes forever to boot, so I use kexec to boot > into new kernels. Works fine, but some time past 2.6.32 it stopped > working. Instead of wasting brain cycles on finding out why, I handed > the problem to my trusty regression friend - git bisect. > > This is what it found (sorry Yinghai it's you again, you owe me a beer > for hours of 2.6.32-git bisecting ;-) sure. > > > 99935a7a59eaca0292c1a5880e10bae03f4a5e3d is the first bad commit > commit 99935a7a59eaca0292c1a5880e10bae03f4a5e3d > Author: Yinghai Lu <yinghai(a)kernel.org> > Date: Sun Oct 4 21:54:24 2009 -0700 > > x86/PCI: read root resources from IOH on Intel > > For intel systems with multi IOH, we should read peer root resources > directly from PCI config space, and don't trust _CRS. > > > I could not revert this single commit, as a further commit made other > changes. So I reverted 67f241f4 first and then 99935a7a. I confirmed > that this kernel then works fine. > let see how BIOS mess it up again! > With current -git, I get tons and tons of: > > [ 16.841724] pci 0000:00:01.0: BAR 7: no parent found for bridge [io > 0x6000-0x6fff] > [ 16.850368] pci 0000:00:01.0: BAR 7: can't allocate [io > 0x6000-0x6fff] > [ 16.857821] pci 0000:00:01.0: BAR 8: no parent found for bridge [mem > 0x9bc00000-0x9bcfffff] > [ 16.867238] pci 0000:00:01.0: BAR 8: can't allocate [mem > 0x9bc00000-0x9bcfffff] > [ 16.875492] pci 0000:00:02.0: BAR 7: no parent found for bridge [io > 0x5000-0x5fff] > [ 16.884137] pci 0000:00:02.0: BAR 7: can't allocate [io > 0x5000-0x5fff] > [ 16.891591] pci 0000:00:02.0: BAR 8: no parent found for bridge [mem > 0x9bb00000-0x9bbfffff] > [ 16.901010] pci 0000:00:02.0: BAR 8: can't allocate [mem > 0x9bb00000-0x9bbfffff] > [ 16.909264] pci 0000:00:03.0: BAR 7: no parent found for bridge [io > 0x4000-0x4fff] > [ 16.917908] pci 0000:00:03.0: BAR 7: can't allocate [io > 0x4000-0x4fff] > [...] > > I can provide a full log if needed. please. YH -- 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: Jens Axboe on 15 Dec 2009 07:20 On Tue, Dec 15 2009, Yinghai Lu wrote: > Jens Axboe wrote: > > Hi, > > > > I have this big box that takes forever to boot, so I use kexec to boot > > into new kernels. Works fine, but some time past 2.6.32 it stopped > > working. Instead of wasting brain cycles on finding out why, I handed > > the problem to my trusty regression friend - git bisect. > > > > This is what it found (sorry Yinghai it's you again, you owe me a beer > > for hours of 2.6.32-git bisecting ;-) > > sure. > > > > > > > 99935a7a59eaca0292c1a5880e10bae03f4a5e3d is the first bad commit > > commit 99935a7a59eaca0292c1a5880e10bae03f4a5e3d > > Author: Yinghai Lu <yinghai(a)kernel.org> > > Date: Sun Oct 4 21:54:24 2009 -0700 > > > > x86/PCI: read root resources from IOH on Intel > > > > For intel systems with multi IOH, we should read peer root resources > > directly from PCI config space, and don't trust _CRS. > > > > > > I could not revert this single commit, as a further commit made other > > changes. So I reverted 67f241f4 first and then 99935a7a. I confirmed > > that this kernel then works fine. > > > > let see how BIOS mess it up again! Heh, I had a feeling this was coming :-) > please. Please find two logs attached - one from a boot with -git and the two patches reverted, and one from a boot with -git. -- Jens Axboe
From: Yinghai Lu on 15 Dec 2009 07:40 Jens Axboe wrote: > On Tue, Dec 15 2009, Yinghai Lu wrote: >> Jens Axboe wrote: >>> Hi, >>> >>> I have this big box that takes forever to boot, so I use kexec to boot >>> into new kernels. Works fine, but some time past 2.6.32 it stopped >>> working. Instead of wasting brain cycles on finding out why, I handed >>> the problem to my trusty regression friend - git bisect. >>> >>> This is what it found (sorry Yinghai it's you again, you owe me a beer >>> for hours of 2.6.32-git bisecting ;-) >> sure. >> >>> >>> 99935a7a59eaca0292c1a5880e10bae03f4a5e3d is the first bad commit >>> commit 99935a7a59eaca0292c1a5880e10bae03f4a5e3d >>> Author: Yinghai Lu <yinghai(a)kernel.org> >>> Date: Sun Oct 4 21:54:24 2009 -0700 >>> >>> x86/PCI: read root resources from IOH on Intel >>> >>> For intel systems with multi IOH, we should read peer root resources >>> directly from PCI config space, and don't trust _CRS. >>> >>> >>> I could not revert this single commit, as a further commit made other >>> changes. So I reverted 67f241f4 first and then 99935a7a. I confirmed >>> that this kernel then works fine. >>> >> let see how BIOS mess it up again! > > Heh, I had a feeling this was coming :-) > >> please. > > Please find two logs attached - one from a boot with -git and the two > patches reverted, and one from a boot with -git. please enabled CONFIG_PCI_DEBUG and boot with debug in boot command line. Thanks Yinghai -- 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: Jens Axboe on 15 Dec 2009 07:50
On Tue, Dec 15 2009, Yinghai Lu wrote: > Jens Axboe wrote: > > On Tue, Dec 15 2009, Yinghai Lu wrote: > >> Jens Axboe wrote: > >>> Hi, > >>> > >>> I have this big box that takes forever to boot, so I use kexec to boot > >>> into new kernels. Works fine, but some time past 2.6.32 it stopped > >>> working. Instead of wasting brain cycles on finding out why, I handed > >>> the problem to my trusty regression friend - git bisect. > >>> > >>> This is what it found (sorry Yinghai it's you again, you owe me a beer > >>> for hours of 2.6.32-git bisecting ;-) > >> sure. > >> > >>> > >>> 99935a7a59eaca0292c1a5880e10bae03f4a5e3d is the first bad commit > >>> commit 99935a7a59eaca0292c1a5880e10bae03f4a5e3d > >>> Author: Yinghai Lu <yinghai(a)kernel.org> > >>> Date: Sun Oct 4 21:54:24 2009 -0700 > >>> > >>> x86/PCI: read root resources from IOH on Intel > >>> > >>> For intel systems with multi IOH, we should read peer root resources > >>> directly from PCI config space, and don't trust _CRS. > >>> > >>> > >>> I could not revert this single commit, as a further commit made other > >>> changes. So I reverted 67f241f4 first and then 99935a7a. I confirmed > >>> that this kernel then works fine. > >>> > >> let see how BIOS mess it up again! > > > > Heh, I had a feeling this was coming :-) > > > >> please. > > > > Please find two logs attached - one from a boot with -git and the two > > patches reverted, and one from a boot with -git. > > please enabled CONFIG_PCI_DEBUG and boot with debug in boot command line. On the good or bad kernel? -- Jens Axboe -- 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/ |