Re: [patch 00/31] 2.6.20-stable review
On Tue, Mar 20, 2007 at 11:53:55PM -0400, Gene Heskett wrote:
> On Tuesday 20 March 2007, Greg KH wrote:
> [...]
> >> It looks like, from the series files contents, that I grabbed the
> >> wrong 'queue', its all 2.6.21 stuff. url please.
> >
> >The patch queue can be found at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
> >
> >All of the patches and the series file are in the review-2.6.20/
> >directory.
>
> This is not available via ftp? My git is git version 0.99.7d, veddy veddy
> long in the tooth by now I suspect. And, apparently no manpages. Humm,
> smart is still running, maybe it has a newer git that's more conversant
> with your syntax. Yup smart is pulling it in now. Later, thanks.
The attached patch was already reported as being responsible for a
different regression.
Does reverting it help?
If not, and if you'll need any help with bisecting for the guilty patch,
please send me a private email.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
>From [EMAIL PROTECTED] Tue Mar 13 11:05:30 2007
From: Jan Beulich <[EMAIL PROTECTED]>
Date: Tue, 13 Mar 2007 14:04:11 -0400
Subject: adjust legacy IDE resource setting (v2)
To: linux-stable <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
From: Jan Beulich <[EMAIL PROTECTED]>
adjust legacy IDE resource setting (v2)
The change to force legacy mode IDE channels' resources to fixed non-zero
values confuses (at least some versions of) X, because the values reported
by the kernel and those readable from PCI config space aren't consistent
anymore. Therefore, this patch arranges for the respective BARs to also
get updated if possible.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
Acked-by: Alan Cox <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
Cc: Chuck Ebbert <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/pci/probe.c | 45 -
1 file changed, 32 insertions(+), 13 deletions(-)
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -639,7 +639,34 @@ static void pci_read_irq(struct pci_dev
dev->irq = irq;
}
-#define LEGACY_IO_RESOURCE (IORESOURCE_IO | IORESOURCE_PCI_FIXED)
+static void change_legacy_io_resource(struct pci_dev * dev, unsigned index,
+ unsigned start, unsigned end)
+{
+ unsigned base = start & PCI_BASE_ADDRESS_IO_MASK;
+ unsigned len = (end | ~PCI_BASE_ADDRESS_IO_MASK) - base + 1;
+
+ /*
+ * Some X versions get confused when the BARs reported through
+ * /sys or /proc differ from those seen in config space, thus
+ * try to update the config space values, too.
+ */
+ if (!(pci_resource_flags(dev, index) & IORESOURCE_IO))
+ printk(KERN_WARNING "%s: cannot adjust BAR%u (not I/O)\n",
+ pci_name(dev), index);
+ else if (pci_resource_len(dev, index) != len)
+ printk(KERN_WARNING "%s: cannot adjust BAR%u (size %04X)\n",
+ pci_name(dev), index, (unsigned)pci_resource_len(dev, index));
+ else {
+ printk(KERN_INFO "%s: trying to change BAR%u from %04X to %04X\n",
+ pci_name(dev), index,
+ (unsigned)pci_resource_start(dev, index), base);
+ pci_write_config_dword(dev, PCI_BASE_ADDRESS_0 + index * 4, base);
+ }
+ pci_resource_start(dev, index) = start;
+ pci_resource_end(dev, index) = end;
+ pci_resource_flags(dev, index) =
+ IORESOURCE_IO | IORESOURCE_PCI_FIXED | PCI_BASE_ADDRESS_SPACE_IO;
+}
/**
* pci_setup_device - fill in class and map information of a device
@@ -692,20 +719,12 @@ static int pci_setup_device(struct pci_d
u8 progif;
pci_read_config_byte(dev, PCI_CLASS_PROG, );
if ((progif & 1) == 0) {
-dev->resource[0].start = 0x1F0;
-dev->resource[0].end = 0x1F7;
-dev->resource[0].flags = LEGACY_IO_RESOURCE;
-dev->resource[1].start = 0x3F6;
-dev->resource[1].end = 0x3F6;
-dev->resource[1].flags = LEGACY_IO_RESOURCE;
+change_legacy_io_resource(dev, 0, 0x1F0, 0x1F7);
+change_legacy_io_resource(dev, 1, 0x3F6, 0x3F6);
}
if ((progif & 4) == 0) {
-dev->resource[2].start = 0x170;
-dev->resource[2].end = 0x177;
-dev->resource[2].flags = LEGACY_IO_RESOURCE;
-dev->resource[3].start = 0x376;
-dev->resource[3].end = 0x376;
-dev->resource[3].flags = LEGACY_IO_RESOURCE;
+change_legacy_io_resource(dev, 2, 0x170, 0x177);
+change_legacy_io_resource(dev, 3, 0x376, 0x376);
}
}
break;
Re: [patch 00/31] 2.6.20-stable review
On Tue, Mar 20, 2007 at 11:53:55PM -0400, Gene Heskett wrote:
On Tuesday 20 March 2007, Greg KH wrote:
[...]
It looks like, from the series files contents, that I grabbed the
wrong 'queue', its all 2.6.21 stuff. url please.
The patch queue can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
All of the patches and the series file are in the review-2.6.20/
directory.
This is not available via ftp? My git is git version 0.99.7d, veddy veddy
long in the tooth by now I suspect. And, apparently no manpages. Humm,
smart is still running, maybe it has a newer git that's more conversant
with your syntax. Yup smart is pulling it in now. Later, thanks.
The attached patch was already reported as being responsible for a
different regression.
Does reverting it help?
If not, and if you'll need any help with bisecting for the guilty patch,
please send me a private email.
cu
Adrian
--
Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
Only a promise, Lao Er said.
Pearl S. Buck - Dragon Seed
From [EMAIL PROTECTED] Tue Mar 13 11:05:30 2007
From: Jan Beulich [EMAIL PROTECTED]
Date: Tue, 13 Mar 2007 14:04:11 -0400
Subject: adjust legacy IDE resource setting (v2)
To: linux-stable [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
From: Jan Beulich [EMAIL PROTECTED]
adjust legacy IDE resource setting (v2)
The change to force legacy mode IDE channels' resources to fixed non-zero
values confuses (at least some versions of) X, because the values reported
by the kernel and those readable from PCI config space aren't consistent
anymore. Therefore, this patch arranges for the respective BARs to also
get updated if possible.
Signed-off-by: Jan Beulich [EMAIL PROTECTED]
Acked-by: Alan Cox [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
Cc: Chuck Ebbert [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
---
drivers/pci/probe.c | 45 -
1 file changed, 32 insertions(+), 13 deletions(-)
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -639,7 +639,34 @@ static void pci_read_irq(struct pci_dev
dev-irq = irq;
}
-#define LEGACY_IO_RESOURCE (IORESOURCE_IO | IORESOURCE_PCI_FIXED)
+static void change_legacy_io_resource(struct pci_dev * dev, unsigned index,
+ unsigned start, unsigned end)
+{
+ unsigned base = start PCI_BASE_ADDRESS_IO_MASK;
+ unsigned len = (end | ~PCI_BASE_ADDRESS_IO_MASK) - base + 1;
+
+ /*
+ * Some X versions get confused when the BARs reported through
+ * /sys or /proc differ from those seen in config space, thus
+ * try to update the config space values, too.
+ */
+ if (!(pci_resource_flags(dev, index) IORESOURCE_IO))
+ printk(KERN_WARNING %s: cannot adjust BAR%u (not I/O)\n,
+ pci_name(dev), index);
+ else if (pci_resource_len(dev, index) != len)
+ printk(KERN_WARNING %s: cannot adjust BAR%u (size %04X)\n,
+ pci_name(dev), index, (unsigned)pci_resource_len(dev, index));
+ else {
+ printk(KERN_INFO %s: trying to change BAR%u from %04X to %04X\n,
+ pci_name(dev), index,
+ (unsigned)pci_resource_start(dev, index), base);
+ pci_write_config_dword(dev, PCI_BASE_ADDRESS_0 + index * 4, base);
+ }
+ pci_resource_start(dev, index) = start;
+ pci_resource_end(dev, index) = end;
+ pci_resource_flags(dev, index) =
+ IORESOURCE_IO | IORESOURCE_PCI_FIXED | PCI_BASE_ADDRESS_SPACE_IO;
+}
/**
* pci_setup_device - fill in class and map information of a device
@@ -692,20 +719,12 @@ static int pci_setup_device(struct pci_d
u8 progif;
pci_read_config_byte(dev, PCI_CLASS_PROG, progif);
if ((progif 1) == 0) {
-dev-resource[0].start = 0x1F0;
-dev-resource[0].end = 0x1F7;
-dev-resource[0].flags = LEGACY_IO_RESOURCE;
-dev-resource[1].start = 0x3F6;
-dev-resource[1].end = 0x3F6;
-dev-resource[1].flags = LEGACY_IO_RESOURCE;
+change_legacy_io_resource(dev, 0, 0x1F0, 0x1F7);
+change_legacy_io_resource(dev, 1, 0x3F6, 0x3F6);
}
if ((progif 4) == 0) {
-dev-resource[2].start = 0x170;
-dev-resource[2].end = 0x177;
-dev-resource[2].flags = LEGACY_IO_RESOURCE;
-dev-resource[3].start = 0x376;
-dev-resource[3].end = 0x376;
-dev-resource[3].flags = LEGACY_IO_RESOURCE;
+change_legacy_io_resource(dev, 2, 0x170, 0x177);
+change_legacy_io_resource(dev, 3, 0x376, 0x376);
}
}
break;
Re: [patch 00/31] 2.6.20-stable review
On Tuesday 20 March 2007, Greg KH wrote: [...] >> It looks like, from the series files contents, that I grabbed the >> wrong 'queue', its all 2.6.21 stuff. url please. > >The patch queue can be found at: > git://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git > >All of the patches and the series file are in the review-2.6.20/ >directory. This is not available via ftp? My git is git version 0.99.7d, veddy veddy long in the tooth by now I suspect. And, apparently no manpages. Humm, smart is still running, maybe it has a newer git that's more conversant with your syntax. Yup smart is pulling it in now. Later, thanks. >thanks, > >greg k-h -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) When I works, I works hard. When I sits, I sits easy. And when I thinks, I goes to sleep. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/31] 2.6.20-stable review
On Tue, Mar 20, 2007 at 11:04:43PM -0400, Gene Heskett wrote: > On Tuesday 20 March 2007, Michael Krufky wrote: > >Gene Heskett wrote: > >> On Tuesday 20 March 2007, Greg KH wrote: > >>> On Tue, Mar 20, 2007 at 01:15:02AM -0400, Gene Heskett wrote: > In any event, something tickled the monster, and its hungry. This > is a full-stop, show-stopper AFAIAC. > > I'll cut that patch-2.6.20.4-rc1 in halves, and build 2 more test > kernels tomorrow to start a bisect if no one has any better idea > before then. > >>> > >>> I'd recommend using the quilt tree of patches to do this, it will be > >>> easier than trying to split the larger patch up into pieces by hand. > >>> > >>> thanks, > >>> > >>> greg k-h > >> > >> I don't have quilt installed, and no idea how to use it if it was, > >> Greg. Even my git is now pushing a year old. > > > >Gene- > > > >quilt is a very easy tool to use... Here is a quick run-down. > > > >#1) remove the stable -rc patch from the tree > > > >#2) install quilt > > > >#3) go to your source tree, and create a directory called "patches" > > > >#4) copy all of the patches from Greg's queue into that "patches" > > directory, including the "series" file. > > > >#5) quilt push, to apply the first patch > >quilt push, to apply the second patch (you get the idea) > >quilt push -a , to apply all patches in the series > > > >#6) quilt pop, to back out the most recent patch pushed in > >quilt pop -a to back out the entire series. > > > >If a patch doesnt apply, quilt will let you know about it, and present > > you with the option to force the patch to apply. This is highly > > unlikely to occur, since Greg has already done what needs to be done to > > make these patches apply to the source. > > > >For a better explanation, see "man quilt". Using quilt, when you have a > > list of patches and a series file containing the merge order is *much* > > easier that a git bisection, and can help you to find the problem patch > > much quicker. > > > >I hope this helps... > > > It looks like, from the series files contents, that I grabbed the > wrong 'queue', its all 2.6.21 stuff. url please. The patch queue can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git All of the patches and the series file are in the review-2.6.20/ directory. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/31] 2.6.20-stable review
On Tuesday 20 March 2007, Michael Krufky wrote: >Gene Heskett wrote: >> On Tuesday 20 March 2007, Greg KH wrote: >>> On Tue, Mar 20, 2007 at 01:15:02AM -0400, Gene Heskett wrote: In any event, something tickled the monster, and its hungry. This is a full-stop, show-stopper AFAIAC. I'll cut that patch-2.6.20.4-rc1 in halves, and build 2 more test kernels tomorrow to start a bisect if no one has any better idea before then. >>> >>> I'd recommend using the quilt tree of patches to do this, it will be >>> easier than trying to split the larger patch up into pieces by hand. >>> >>> thanks, >>> >>> greg k-h >> >> I don't have quilt installed, and no idea how to use it if it was, >> Greg. Even my git is now pushing a year old. > >Gene- > >quilt is a very easy tool to use... Here is a quick run-down. > >#1) remove the stable -rc patch from the tree > >#2) install quilt > >#3) go to your source tree, and create a directory called "patches" > >#4) copy all of the patches from Greg's queue into that "patches" > directory, including the "series" file. > >#5) quilt push, to apply the first patch >quilt push, to apply the second patch (you get the idea) >quilt push -a , to apply all patches in the series > >#6) quilt pop, to back out the most recent patch pushed in >quilt pop -a to back out the entire series. > >If a patch doesnt apply, quilt will let you know about it, and present > you with the option to force the patch to apply. This is highly > unlikely to occur, since Greg has already done what needs to be done to > make these patches apply to the source. > >For a better explanation, see "man quilt". Using quilt, when you have a > list of patches and a series file containing the merge order is *much* > easier that a git bisection, and can help you to find the problem patch > much quicker. > >I hope this helps... > It looks like, from the series files contents, that I grabbed the wrong 'queue', its all 2.6.21 stuff. url please. Thanks. >Good Luck, > >Michael Krufky -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) "You show me an American who can keep his mouth shut and I'll eat him." -- Newspaperman from Frank Capra's _Meet_John_Doe_ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/31] 2.6.20-stable review
On Tuesday 20 March 2007, Michael Krufky wrote: >Gene Heskett wrote: >> On Tuesday 20 March 2007, Greg KH wrote: >>> On Tue, Mar 20, 2007 at 01:15:02AM -0400, Gene Heskett wrote: In any event, something tickled the monster, and its hungry. This is a full-stop, show-stopper AFAIAC. I'll cut that patch-2.6.20.4-rc1 in halves, and build 2 more test kernels tomorrow to start a bisect if no one has any better idea before then. >>> >>> I'd recommend using the quilt tree of patches to do this, it will be >>> easier than trying to split the larger patch up into pieces by hand. >>> >>> thanks, >>> >>> greg k-h >> >> I don't have quilt installed, and no idea how to use it if it was, >> Greg. Even my git is now pushing a year old. > >Gene- > >quilt is a very easy tool to use... Here is a quick run-down. > >#1) remove the stable -rc patch from the tree > >#2) install quilt > >#3) go to your source tree, and create a directory called "patches" > >#4) copy all of the patches from Greg's queue into that "patches" > directory, including the "series" file. I hope by Greg's queue you meant: As that's the tree I just pulled in and put in /usr/src/patches with gftp. >#5) quilt push, to apply the first patch >quilt push, to apply the second patch (you get the idea) >quilt push -a , to apply all patches in the series >#6) quilt pop, to back out the most recent patch pushed in >quilt pop -a to back out the entire series. > >If a patch doesnt apply, quilt will let you know about it, and present > you with the option to force the patch to apply. This is highly > unlikely to occur, since Greg has already done what needs to be done to > make these patches apply to the source. > >For a better explanation, see "man quilt". Using quilt, when you have a > list of patches and a series file containing the merge order is *much* > easier that a git bisection, and can help you to find the problem patch > much quicker. > >I hope this helps... I do too, but I'm now less than 2 hours from the backup run, which with this currently running kernel, should be a sane one. ? Since this will start with a patch level of a 2.6.20.3 kernel (or is that patch level a mistaken assumption on my part, but I haven't reversed the 2.6.20.4-rc1 patch yet, that's next.), and I have to edit both the Makefile and my 'makeit' script so the names all match, what makes a good naming convention while I'm doing this? This might all be clear once I read the quilt manpage, which I haven't had a chance to do yet. That is next, after I reverse that patch. >Good Luck, > >Michael Krufky -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) The chief cause of problems is solutions. -- Eric Sevareid - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/31] 2.6.20-stable review
Gene Heskett wrote: > On Tuesday 20 March 2007, Greg KH wrote: >> On Tue, Mar 20, 2007 at 01:15:02AM -0400, Gene Heskett wrote: >>> In any event, something tickled the monster, and its hungry. This is >>> a full-stop, show-stopper AFAIAC. >>> >>> I'll cut that patch-2.6.20.4-rc1 in halves, and build 2 more test >>> kernels tomorrow to start a bisect if no one has any better idea >>> before then. >> I'd recommend using the quilt tree of patches to do this, it will be >> easier than trying to split the larger patch up into pieces by hand. >> >> thanks, >> >> greg k-h > > I don't have quilt installed, and no idea how to use it if it was, Greg. > Even my git is now pushing a year old. > Gene- quilt is a very easy tool to use... Here is a quick run-down. #1) remove the stable -rc patch from the tree #2) install quilt #3) go to your source tree, and create a directory called "patches" #4) copy all of the patches from Greg's queue into that "patches" directory, including the "series" file. #5) quilt push, to apply the first patch quilt push, to apply the second patch (you get the idea) quilt push -a , to apply all patches in the series #6) quilt pop, to back out the most recent patch pushed in quilt pop -a to back out the entire series. If a patch doesnt apply, quilt will let you know about it, and present you with the option to force the patch to apply. This is highly unlikely to occur, since Greg has already done what needs to be done to make these patches apply to the source. For a better explanation, see "man quilt". Using quilt, when you have a list of patches and a series file containing the merge order is *much* easier that a git bisection, and can help you to find the problem patch much quicker. I hope this helps... Good Luck, Michael Krufky - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/31] 2.6.20-stable review
On Tuesday 20 March 2007, Greg KH wrote: >On Tue, Mar 20, 2007 at 01:15:02AM -0400, Gene Heskett wrote: >> In any event, something tickled the monster, and its hungry. This is >> a full-stop, show-stopper AFAIAC. >> >> I'll cut that patch-2.6.20.4-rc1 in halves, and build 2 more test >> kernels tomorrow to start a bisect if no one has any better idea >> before then. > >I'd recommend using the quilt tree of patches to do this, it will be >easier than trying to split the larger patch up into pieces by hand. > >thanks, > >greg k-h I don't have quilt installed, and no idea how to use it if it was, Greg. Even my git is now pushing a year old. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If I were a grave-digger or even a hangman, there are some people I could work for with a great deal of enjoyment. -- Douglas Jerrold - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/31] 2.6.20-stable review
On Tue, Mar 20, 2007 at 01:15:02AM -0400, Gene Heskett wrote: > > In any event, something tickled the monster, and its hungry. This is a > full-stop, show-stopper AFAIAC. > > I'll cut that patch-2.6.20.4-rc1 in halves, and build 2 more test > kernels tomorrow to start a bisect if no one has any better idea > before then. I'd recommend using the quilt tree of patches to do this, it will be easier than trying to split the larger patch up into pieces by hand. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/31] 2.6.20-stable review
On Tue, Mar 20, 2007 at 01:15:02AM -0400, Gene Heskett wrote: In any event, something tickled the monster, and its hungry. This is a full-stop, show-stopper AFAIAC. I'll cut that patch-2.6.20.4-rc1 in halves, and build 2 more test kernels tomorrow to start a bisect if no one has any better idea before then. I'd recommend using the quilt tree of patches to do this, it will be easier than trying to split the larger patch up into pieces by hand. thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/31] 2.6.20-stable review
On Tuesday 20 March 2007, Greg KH wrote: On Tue, Mar 20, 2007 at 01:15:02AM -0400, Gene Heskett wrote: In any event, something tickled the monster, and its hungry. This is a full-stop, show-stopper AFAIAC. I'll cut that patch-2.6.20.4-rc1 in halves, and build 2 more test kernels tomorrow to start a bisect if no one has any better idea before then. I'd recommend using the quilt tree of patches to do this, it will be easier than trying to split the larger patch up into pieces by hand. thanks, greg k-h I don't have quilt installed, and no idea how to use it if it was, Greg. Even my git is now pushing a year old. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) If I were a grave-digger or even a hangman, there are some people I could work for with a great deal of enjoyment. -- Douglas Jerrold - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/31] 2.6.20-stable review
Gene Heskett wrote: On Tuesday 20 March 2007, Greg KH wrote: On Tue, Mar 20, 2007 at 01:15:02AM -0400, Gene Heskett wrote: In any event, something tickled the monster, and its hungry. This is a full-stop, show-stopper AFAIAC. I'll cut that patch-2.6.20.4-rc1 in halves, and build 2 more test kernels tomorrow to start a bisect if no one has any better idea before then. I'd recommend using the quilt tree of patches to do this, it will be easier than trying to split the larger patch up into pieces by hand. thanks, greg k-h I don't have quilt installed, and no idea how to use it if it was, Greg. Even my git is now pushing a year old. Gene- quilt is a very easy tool to use... Here is a quick run-down. #1) remove the stable -rc patch from the tree #2) install quilt #3) go to your source tree, and create a directory called patches #4) copy all of the patches from Greg's queue into that patches directory, including the series file. #5) quilt push, to apply the first patch quilt push, to apply the second patch (you get the idea) quilt push -a , to apply all patches in the series #6) quilt pop, to back out the most recent patch pushed in quilt pop -a to back out the entire series. If a patch doesnt apply, quilt will let you know about it, and present you with the option to force the patch to apply. This is highly unlikely to occur, since Greg has already done what needs to be done to make these patches apply to the source. For a better explanation, see man quilt. Using quilt, when you have a list of patches and a series file containing the merge order is *much* easier that a git bisection, and can help you to find the problem patch much quicker. I hope this helps... Good Luck, Michael Krufky - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/31] 2.6.20-stable review
On Tuesday 20 March 2007, Michael Krufky wrote: Gene Heskett wrote: On Tuesday 20 March 2007, Greg KH wrote: On Tue, Mar 20, 2007 at 01:15:02AM -0400, Gene Heskett wrote: In any event, something tickled the monster, and its hungry. This is a full-stop, show-stopper AFAIAC. I'll cut that patch-2.6.20.4-rc1 in halves, and build 2 more test kernels tomorrow to start a bisect if no one has any better idea before then. I'd recommend using the quilt tree of patches to do this, it will be easier than trying to split the larger patch up into pieces by hand. thanks, greg k-h I don't have quilt installed, and no idea how to use it if it was, Greg. Even my git is now pushing a year old. Gene- quilt is a very easy tool to use... Here is a quick run-down. #1) remove the stable -rc patch from the tree #2) install quilt #3) go to your source tree, and create a directory called patches #4) copy all of the patches from Greg's queue into that patches directory, including the series file. I hope by Greg's queue you meant: ftp:ftp.kernel.org:/pub/linux/kernel/people/gregkh/gregkh-2.6/patches As that's the tree I just pulled in and put in /usr/src/patches with gftp. #5) quilt push, to apply the first patch quilt push, to apply the second patch (you get the idea) quilt push -a , to apply all patches in the series #6) quilt pop, to back out the most recent patch pushed in quilt pop -a to back out the entire series. If a patch doesnt apply, quilt will let you know about it, and present you with the option to force the patch to apply. This is highly unlikely to occur, since Greg has already done what needs to be done to make these patches apply to the source. For a better explanation, see man quilt. Using quilt, when you have a list of patches and a series file containing the merge order is *much* easier that a git bisection, and can help you to find the problem patch much quicker. I hope this helps... I do too, but I'm now less than 2 hours from the backup run, which with this currently running kernel, should be a sane one. ? Since this will start with a patch level of a 2.6.20.3 kernel (or is that patch level a mistaken assumption on my part, but I haven't reversed the 2.6.20.4-rc1 patch yet, that's next.), and I have to edit both the Makefile and my 'makeit' script so the names all match, what makes a good naming convention while I'm doing this? This might all be clear once I read the quilt manpage, which I haven't had a chance to do yet. That is next, after I reverse that patch. Good Luck, Michael Krufky -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) The chief cause of problems is solutions. -- Eric Sevareid - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/31] 2.6.20-stable review
On Tuesday 20 March 2007, Michael Krufky wrote: Gene Heskett wrote: On Tuesday 20 March 2007, Greg KH wrote: On Tue, Mar 20, 2007 at 01:15:02AM -0400, Gene Heskett wrote: In any event, something tickled the monster, and its hungry. This is a full-stop, show-stopper AFAIAC. I'll cut that patch-2.6.20.4-rc1 in halves, and build 2 more test kernels tomorrow to start a bisect if no one has any better idea before then. I'd recommend using the quilt tree of patches to do this, it will be easier than trying to split the larger patch up into pieces by hand. thanks, greg k-h I don't have quilt installed, and no idea how to use it if it was, Greg. Even my git is now pushing a year old. Gene- quilt is a very easy tool to use... Here is a quick run-down. #1) remove the stable -rc patch from the tree #2) install quilt #3) go to your source tree, and create a directory called patches #4) copy all of the patches from Greg's queue into that patches directory, including the series file. #5) quilt push, to apply the first patch quilt push, to apply the second patch (you get the idea) quilt push -a , to apply all patches in the series #6) quilt pop, to back out the most recent patch pushed in quilt pop -a to back out the entire series. If a patch doesnt apply, quilt will let you know about it, and present you with the option to force the patch to apply. This is highly unlikely to occur, since Greg has already done what needs to be done to make these patches apply to the source. For a better explanation, see man quilt. Using quilt, when you have a list of patches and a series file containing the merge order is *much* easier that a git bisection, and can help you to find the problem patch much quicker. I hope this helps... It looks like, from the series files contents, that I grabbed the wrong 'queue', its all 2.6.21 stuff. url please. Thanks. Good Luck, Michael Krufky -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) You show me an American who can keep his mouth shut and I'll eat him. -- Newspaperman from Frank Capra's _Meet_John_Doe_ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/31] 2.6.20-stable review
On Tue, Mar 20, 2007 at 11:04:43PM -0400, Gene Heskett wrote: On Tuesday 20 March 2007, Michael Krufky wrote: Gene Heskett wrote: On Tuesday 20 March 2007, Greg KH wrote: On Tue, Mar 20, 2007 at 01:15:02AM -0400, Gene Heskett wrote: In any event, something tickled the monster, and its hungry. This is a full-stop, show-stopper AFAIAC. I'll cut that patch-2.6.20.4-rc1 in halves, and build 2 more test kernels tomorrow to start a bisect if no one has any better idea before then. I'd recommend using the quilt tree of patches to do this, it will be easier than trying to split the larger patch up into pieces by hand. thanks, greg k-h I don't have quilt installed, and no idea how to use it if it was, Greg. Even my git is now pushing a year old. Gene- quilt is a very easy tool to use... Here is a quick run-down. #1) remove the stable -rc patch from the tree #2) install quilt #3) go to your source tree, and create a directory called patches #4) copy all of the patches from Greg's queue into that patches directory, including the series file. #5) quilt push, to apply the first patch quilt push, to apply the second patch (you get the idea) quilt push -a , to apply all patches in the series #6) quilt pop, to back out the most recent patch pushed in quilt pop -a to back out the entire series. If a patch doesnt apply, quilt will let you know about it, and present you with the option to force the patch to apply. This is highly unlikely to occur, since Greg has already done what needs to be done to make these patches apply to the source. For a better explanation, see man quilt. Using quilt, when you have a list of patches and a series file containing the merge order is *much* easier that a git bisection, and can help you to find the problem patch much quicker. I hope this helps... It looks like, from the series files contents, that I grabbed the wrong 'queue', its all 2.6.21 stuff. url please. The patch queue can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git All of the patches and the series file are in the review-2.6.20/ directory. thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/31] 2.6.20-stable review
On Tuesday 20 March 2007, Greg KH wrote: [...] It looks like, from the series files contents, that I grabbed the wrong 'queue', its all 2.6.21 stuff. url please. The patch queue can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git All of the patches and the series file are in the review-2.6.20/ directory. This is not available via ftp? My git is git version 0.99.7d, veddy veddy long in the tooth by now I suspect. And, apparently no manpages. Humm, smart is still running, maybe it has a newer git that's more conversant with your syntax. Yup smart is pulling it in now. Later, thanks. thanks, greg k-h -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) When I works, I works hard. When I sits, I sits easy. And when I thinks, I goes to sleep. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/31] 2.6.20-stable review
On Monday 19 March 2007, Greg KH wrote: >This is the start of the stable review cycle for the 2.6.20.4 release. >There are 31 patches in this series, all will be posted as a response >to this one. If anyone has any issues with these being applied, please >let us know. If anyone is a maintainer of the proper subsystem, and >wants to add a Signed-off-by: line to the patch, please respond with it. > >These patches are sent out with a number of different people on the >Cc: line. If you wish to be a reviewer, please email [EMAIL PROTECTED] >to add your name to the list. If you want to be off the reviewer list, >also email us. > >Responses should be made by Thursday March, 22, 15:00:00 UTC. >Anything received after that time might be too late. BINGO! One of these 31 patches may be the guilty party that's playing tricks with tar's mind. I'm running 2.6.20.4-rc1 on an older athlon xp2800 with a gig of ram. Amanda has gotten through the estimate phase and is now doing the backup. It will fail, out of tape. Here is an amstatus output as its running right now. coyote:/GenesAmandaHelper-0.5 3 planner: [dumps way too big, 350850 KB, must skip incremental dumps] coyote:/GenesAmandaHelper-0.6 1 planner: [dumps way too big, 184977 KB, must skip incremental dumps] coyote:/bin 1 planner: [dumps way too big, 1110 KB, must skip incremental dumps] coyote:/boot 13m wait for dumping coyote:/dev 1 planner: [dumps way too big, 290 KB, must skip incremental dumps] coyote:/etc 1 planner: [dumps way too big, 18291 KB, must skip incremental dumps] coyote:/home 0 1018m wait for dumping coyote:/lib 3 planner: [dumps way too big, 11705 KB, must skip incremental dumps] coyote:/opt 15m wait for dumping coyote:/root 3 planner: [dumps way too big, 785963 KB, must skip incremental dumps] coyote:/sbin 1 planner: [dumps way too big, 10 KB, must skip incremental dumps] coyote:/tmp 4 32m wait for dumping coyote:/usr/X11R6 12m wait for dumping coyote:/usr/bin 1 planner: [dumps way too big, 339170 KB, must skip incremental dumps] coyote:/usr/dlds 1 planner: [dumps way too big, 2140 KB, must skip incremental dumps] coyote:/usr/dlds-misc 30m wait for dumping coyote:/usr/dlds-rpms 1 planner: [dumps way too big, 3130 KB, must skip incremental dumps] coyote:/usr/dlds-tgzs 1 planner: [dumps way too big, 10 KB, must skip incremental dumps] coyote:/usr/games 00m wait for dumping coyote:/usr/include 1 planner: [dumps way too big, 10557 KB, must skip incremental dumps] coyote:/usr/kerberos 10m wait for dumping coyote:/usr/lib 1 planner: [dumps way too big, 474409 KB, must skip incremental dumps] coyote:/usr/libexec 2 planner: [dumps way too big, 11285 KB, must skip incremental dumps] coyote:/usr/local 2 279m wait for dumping coyote:/usr/man 10m wait for dumping coyote:/usr/movies2 7271m dumping 5485m ( 75.44%) (0:12:47) coyote:/usr/music 1 planner: [dumps way too big, 2448290 KB, must skip incremental dumps] coyote:/usr/pix 2 17m wait for dumping coyote:/usr/sbin 1 planner: [dumps way too big, 3254 KB, must skip incremental dumps] coyote:/usr/share 3 planner: [dumps way too big, 40514 KB, must skip incremental dumps] coyote:/usr/src 3 6822m wait for dumping coyote:/var 1 366m wait for dumping SUMMARY part real estimated size size partition : 32 estimated : 3231973m flush : 0 0m failed : 1816155m ( 50.53%) wait for dumping: 13 8547m ( 26.73%) dumping to tape : 00m ( 0.00%) dumping : 1 5485m 7271m ( 75.44%) ( 17.16%) dumped : 0 0m 0m ( 0.00%) ( 0.00%) wait for writing: 0 0m 0m ( 0.00%) ( 0.00%) wait to flush : 0 0m 0m (100.00%) ( 0.00%) writing to tape : 0 0m 0m ( 0.00%) ( 0.00%) failed to tape : 0 0m 0m ( 0.00%) ( 0.00%) taped : 0 0m 0m ( 0.00%) ( 0.00%) tape 1: 0 0m 0m ( 0.00%) Dailys-19 8 dumpers idle : not-idle taper idle network free kps: 6800 holding space : 71118m (100.00%) dumper0 busy : 0:00:00 ( 0.00%) 0 dumpers busy : 0:00:00 ( 0.00%) 1 dumper busy : 0:00:00 ( 0.00%) The directory shown on line one of this report actually has: [EMAIL PROTECTED] /]# du -h /GenesAmandaHelper-0.5/ 1.6G
Re: [patch 00/31] 2.6.20-stable review
On Mon, Mar 19, 2007 at 02:36:47PM -0700, Greg KH wrote: > This is the start of the stable review cycle for the 2.6.20.4 release. A 2.6.20.4-rc1 patch is also availble at: kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.20.4-rc1.gz thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 00/31] 2.6.20-stable review
This is the start of the stable review cycle for the 2.6.20.4 release. There are 31 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it. These patches are sent out with a number of different people on the Cc: line. If you wish to be a reviewer, please email [EMAIL PROTECTED] to add your name to the list. If you want to be off the reviewer list, also email us. Responses should be made by Thursday March, 22, 15:00:00 UTC. Anything received after that time might be too late. thanks, the -stable release team - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 00/31] 2.6.20-stable review
This is the start of the stable review cycle for the 2.6.20.4 release. There are 31 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it. These patches are sent out with a number of different people on the Cc: line. If you wish to be a reviewer, please email [EMAIL PROTECTED] to add your name to the list. If you want to be off the reviewer list, also email us. Responses should be made by Thursday March, 22, 15:00:00 UTC. Anything received after that time might be too late. thanks, the -stable release team - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/31] 2.6.20-stable review
On Mon, Mar 19, 2007 at 02:36:47PM -0700, Greg KH wrote: This is the start of the stable review cycle for the 2.6.20.4 release. A 2.6.20.4-rc1 patch is also availble at: kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.20.4-rc1.gz thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/31] 2.6.20-stable review
On Monday 19 March 2007, Greg KH wrote: This is the start of the stable review cycle for the 2.6.20.4 release. There are 31 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it. These patches are sent out with a number of different people on the Cc: line. If you wish to be a reviewer, please email [EMAIL PROTECTED] to add your name to the list. If you want to be off the reviewer list, also email us. Responses should be made by Thursday March, 22, 15:00:00 UTC. Anything received after that time might be too late. BINGO! One of these 31 patches may be the guilty party that's playing tricks with tar's mind. I'm running 2.6.20.4-rc1 on an older athlon xp2800 with a gig of ram. Amanda has gotten through the estimate phase and is now doing the backup. It will fail, out of tape. Here is an amstatus output as its running right now. coyote:/GenesAmandaHelper-0.5 3 planner: [dumps way too big, 350850 KB, must skip incremental dumps] coyote:/GenesAmandaHelper-0.6 1 planner: [dumps way too big, 184977 KB, must skip incremental dumps] coyote:/bin 1 planner: [dumps way too big, 1110 KB, must skip incremental dumps] coyote:/boot 13m wait for dumping coyote:/dev 1 planner: [dumps way too big, 290 KB, must skip incremental dumps] coyote:/etc 1 planner: [dumps way too big, 18291 KB, must skip incremental dumps] coyote:/home 0 1018m wait for dumping coyote:/lib 3 planner: [dumps way too big, 11705 KB, must skip incremental dumps] coyote:/opt 15m wait for dumping coyote:/root 3 planner: [dumps way too big, 785963 KB, must skip incremental dumps] coyote:/sbin 1 planner: [dumps way too big, 10 KB, must skip incremental dumps] coyote:/tmp 4 32m wait for dumping coyote:/usr/X11R6 12m wait for dumping coyote:/usr/bin 1 planner: [dumps way too big, 339170 KB, must skip incremental dumps] coyote:/usr/dlds 1 planner: [dumps way too big, 2140 KB, must skip incremental dumps] coyote:/usr/dlds-misc 30m wait for dumping coyote:/usr/dlds-rpms 1 planner: [dumps way too big, 3130 KB, must skip incremental dumps] coyote:/usr/dlds-tgzs 1 planner: [dumps way too big, 10 KB, must skip incremental dumps] coyote:/usr/games 00m wait for dumping coyote:/usr/include 1 planner: [dumps way too big, 10557 KB, must skip incremental dumps] coyote:/usr/kerberos 10m wait for dumping coyote:/usr/lib 1 planner: [dumps way too big, 474409 KB, must skip incremental dumps] coyote:/usr/libexec 2 planner: [dumps way too big, 11285 KB, must skip incremental dumps] coyote:/usr/local 2 279m wait for dumping coyote:/usr/man 10m wait for dumping coyote:/usr/movies2 7271m dumping 5485m ( 75.44%) (0:12:47) coyote:/usr/music 1 planner: [dumps way too big, 2448290 KB, must skip incremental dumps] coyote:/usr/pix 2 17m wait for dumping coyote:/usr/sbin 1 planner: [dumps way too big, 3254 KB, must skip incremental dumps] coyote:/usr/share 3 planner: [dumps way too big, 40514 KB, must skip incremental dumps] coyote:/usr/src 3 6822m wait for dumping coyote:/var 1 366m wait for dumping SUMMARY part real estimated size size partition : 32 estimated : 3231973m flush : 0 0m failed : 1816155m ( 50.53%) wait for dumping: 13 8547m ( 26.73%) dumping to tape : 00m ( 0.00%) dumping : 1 5485m 7271m ( 75.44%) ( 17.16%) dumped : 0 0m 0m ( 0.00%) ( 0.00%) wait for writing: 0 0m 0m ( 0.00%) ( 0.00%) wait to flush : 0 0m 0m (100.00%) ( 0.00%) writing to tape : 0 0m 0m ( 0.00%) ( 0.00%) failed to tape : 0 0m 0m ( 0.00%) ( 0.00%) taped : 0 0m 0m ( 0.00%) ( 0.00%) tape 1: 0 0m 0m ( 0.00%) Dailys-19 8 dumpers idle : not-idle taper idle network free kps: 6800 holding space : 71118m (100.00%) dumper0 busy : 0:00:00 ( 0.00%) 0 dumpers busy : 0:00:00 ( 0.00%) 1 dumper busy : 0:00:00 ( 0.00%) The directory shown on line one of this report actually has: [EMAIL PROTECTED] /]# du -h /GenesAmandaHelper-0.5/ 1.6G
