Re: 2.6.22-rc4-mm1 -- x86_64 ACPI panic
Applied.
thanks,
-Len
On Friday 08 June 2007 14:12, Andrew Morton wrote:
> On Fri, 8 Jun 2007 17:15:45 +0800
> "Luming Yu" <[EMAIL PROTECTED]> wrote:
>
> > The only problem known as to the acpi throttling changes in the mm tree
> > is a typo ,and the patch to fix it is available here. Please test and
> > get results back to me. BTW,the log shows that the acpi-cpufreq.ko has
> > problem. Would please also try not to load acpi-cpufreq.
> >
> > http://www.ussg.iu.edu/hypermail/linux/kernel/0706.0/2509.html
>
> Sigh. Is this some sort of contest to see how many things we can
> do wrong in a single patch?
>
> - Include a changelog
>
> - Include Signed-off-by:
>
> - Don't use attachments
>
> - If you _must_ use attachments, use text/plain, not application/octet-stream
>
> - Format code to remain within 80 columns.
>
> - Don't do "if(". Do "if ("
>
> Oh well. Good to hear that the oops got fixed, thanks.
>
>
> From: "Luming Yu" <[EMAIL PROTECTED]>
>
> Cc: Len Brown <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> ---
>
> drivers/acpi/processor_throttling.c |6 --
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff -puN
> drivers/acpi/processor_throttling.c~acpi-fix-oops-in-acpi_processor_throttling_seq_show
> drivers/acpi/processor_throttling.c
> ---
> a/drivers/acpi/processor_throttling.c~acpi-fix-oops-in-acpi_processor_throttling_seq_show
> +++ a/drivers/acpi/processor_throttling.c
> @@ -656,18 +656,20 @@ static int acpi_processor_throttling_seq
> pr->throttling.state_count - 1);
>
> seq_puts(seq, "states:\n");
> - if (acpi_processor_get_throttling == acpi_processor_get_throttling_fadt)
> + if (pr->throttling.acpi_processor_get_throttling ==
> + acpi_processor_get_throttling_fadt) {
> for (i = 0; i < pr->throttling.state_count; i++)
> seq_printf(seq, " %cT%d: %02d%%\n",
> (i == pr->throttling.state ? '*' : ' '), i,
> (pr->throttling.states[i].performance ? pr->
> throttling.states[i].performance / 10 : 0));
> - else
> + } else {
> for (i = 0; i < pr->throttling.state_count; i++)
> seq_printf(seq, " %cT%d: %02d%%\n",
> (i == pr->throttling.state ? '*' : ' '), i,
> (int)pr->throttling.states_tss[i].
> freqpercentage);
> + }
>
>end:
> return 0;
> _
>
> -
> 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/
>
-
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: 2.6.22-rc4-mm1 -- x86_64 ACPI panic
Applied.
thanks,
-Len
On Friday 08 June 2007 14:12, Andrew Morton wrote:
On Fri, 8 Jun 2007 17:15:45 +0800
Luming Yu [EMAIL PROTECTED] wrote:
The only problem known as to the acpi throttling changes in the mm tree
is a typo ,and the patch to fix it is available here. Please test and
get results back to me. BTW,the log shows that the acpi-cpufreq.ko has
problem. Would please also try not to load acpi-cpufreq.
http://www.ussg.iu.edu/hypermail/linux/kernel/0706.0/2509.html
Sigh. Is this some sort of contest to see how many things we can
do wrong in a single patch?
- Include a changelog
- Include Signed-off-by:
- Don't use attachments
- If you _must_ use attachments, use text/plain, not application/octet-stream
- Format code to remain within 80 columns.
- Don't do if(. Do if (
Oh well. Good to hear that the oops got fixed, thanks.
From: Luming Yu [EMAIL PROTECTED]
Cc: Len Brown [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/acpi/processor_throttling.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff -puN
drivers/acpi/processor_throttling.c~acpi-fix-oops-in-acpi_processor_throttling_seq_show
drivers/acpi/processor_throttling.c
---
a/drivers/acpi/processor_throttling.c~acpi-fix-oops-in-acpi_processor_throttling_seq_show
+++ a/drivers/acpi/processor_throttling.c
@@ -656,18 +656,20 @@ static int acpi_processor_throttling_seq
pr-throttling.state_count - 1);
seq_puts(seq, states:\n);
- if (acpi_processor_get_throttling == acpi_processor_get_throttling_fadt)
+ if (pr-throttling.acpi_processor_get_throttling ==
+ acpi_processor_get_throttling_fadt) {
for (i = 0; i pr-throttling.state_count; i++)
seq_printf(seq,%cT%d: %02d%%\n,
(i == pr-throttling.state ? '*' : ' '), i,
(pr-throttling.states[i].performance ? pr-
throttling.states[i].performance / 10 : 0));
- else
+ } else {
for (i = 0; i pr-throttling.state_count; i++)
seq_printf(seq,%cT%d: %02d%%\n,
(i == pr-throttling.state ? '*' : ' '), i,
(int)pr-throttling.states_tss[i].
freqpercentage);
+ }
end:
return 0;
_
-
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/
-
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: 2.6.22-rc4-mm1
On Sun, Jun 10, 2007 at 10:01:34PM -0700, Dan Williams wrote: > Overall, I feel that async_tx is perhaps justifiably receiving the > silent treatment because offload engines are not a mainstream > occurrence. Currently only people with an Xscale IOP or a PPC 440spe > [4] will notice that mainline lacks support for all the features of > their platform. I see async_tx as a nod to the embedded space where > offload engines act to make up for the absence of multi-Ghz CPUs with > streaming SIMD instructions. > For what it's worth, I'm planning on tying in the SH DMA stuff to the dmaengine code, as the async_tx stuff certainly has quite a few bits of interest. This is probably something I won't get around to for 2.6.23 though, due to time constraints. - 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: 2.6.22-rc4-mm1
On Sun, 10 Jun 2007 22:01:34 -0700 "Dan Williams" <[EMAIL PROTECTED]> wrote: > It would be very helpful to have a clear merge path for dmaengine > changes and the async offload api. Yes, this needs some attention. I'd suggest that you prepare a standalone tree for Linus to pull and we aim at asking him to pull that for 2.6.23-rc1. In the meanwhile I'd suggest that you get the core patch(es) out onto the relevant lists again and cc'ed to the relevant maintainers. Of course, good changelogging and commenting makes the review a) more effective, b) more likely to happen and c) less work for reviewers. The changelog you have for 7556477664edcbe1c9a2fdf60edddfd8455d198b is nice, but it's awfully short for a 1/4MB patch. It tells us at a high level what the code does, but it has nothing to say about how it does it: a high-level design description, of you will. Put yourself in the position of an experienced kernel developer who doesn't know this code, and who doesn't know the hardware. What can you do to make their review easier and more effective? So. Please have a think about what you can do there, and also see what can be done about the 312 warnings which perl scripts/checkpatch.pl patches/git-md-accel.patch emits. Then send 'em all out again (say, a week from now) and let's all just dig in and make this thing happen? - 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: 2.6.22-rc4-mm1
On Sun, 10 Jun 2007 22:01:34 -0700 Dan Williams [EMAIL PROTECTED] wrote: It would be very helpful to have a clear merge path for dmaengine changes and the async offload api. Yes, this needs some attention. I'd suggest that you prepare a standalone tree for Linus to pull and we aim at asking him to pull that for 2.6.23-rc1. In the meanwhile I'd suggest that you get the core patch(es) out onto the relevant lists again and cc'ed to the relevant maintainers. Of course, good changelogging and commenting makes the review a) more effective, b) more likely to happen and c) less work for reviewers. The changelog you have for 7556477664edcbe1c9a2fdf60edddfd8455d198b is nice, but it's awfully short for a 1/4MB patch. It tells us at a high level what the code does, but it has nothing to say about how it does it: a high-level design description, of you will. Put yourself in the position of an experienced kernel developer who doesn't know this code, and who doesn't know the hardware. What can you do to make their review easier and more effective? So. Please have a think about what you can do there, and also see what can be done about the 312 warnings which perl scripts/checkpatch.pl patches/git-md-accel.patch emits. Then send 'em all out again (say, a week from now) and let's all just dig in and make this thing happen? - 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: 2.6.22-rc4-mm1
On Sun, Jun 10, 2007 at 10:01:34PM -0700, Dan Williams wrote: Overall, I feel that async_tx is perhaps justifiably receiving the silent treatment because offload engines are not a mainstream occurrence. Currently only people with an Xscale IOP or a PPC 440spe [4] will notice that mainline lacks support for all the features of their platform. I see async_tx as a nod to the embedded space where offload engines act to make up for the absence of multi-Ghz CPUs with streaming SIMD instructions. For what it's worth, I'm planning on tying in the SH DMA stuff to the dmaengine code, as the async_tx stuff certainly has quite a few bits of interest. This is probably something I won't get around to for 2.6.23 though, due to time constraints. - 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: 2.6.22-rc4-mm1
On 6/7/07, Andrew Morton <[EMAIL PROTECTED]> wrote: On Thu, 7 Jun 2007 17:01:08 +1000 Herbert Xu <[EMAIL PROTECTED]> wrote: > On Thu, Jun 07, 2007 at 08:54:50AM +0200, Jan Engelhardt wrote: > > > > /me points at Herbert > > Andrew would not add options between the "menuconfig CRYPTO" and > > the "if CRYPTO" line... :) > > Actually this patch is not even in my tree :) uh, OK, sorry. > > Index: linux-2.6.22-rc4/crypto/Kconfig > > === > > --- linux-2.6.22-rc4.orig/crypto/Kconfig > > +++ linux-2.6.22-rc4/crypto/Kconfig > > @@ -7,6 +7,8 @@ menuconfig CRYPTO > > help > > This option provides the core Cryptographic API. > > > > +if CRYPTO > > + > > # > > # Generic algorithms support > > # > > @@ -18,8 +20,6 @@ config XOR_BLOCKS > > # > > source "crypto/async_tx/Kconfig" > > Andrew, do you want me to pick the async_tx stuff up instead? > It would be very helpful to have a clear merge path for dmaengine changes and the async offload api. Neil has been extremely helpful reviewing the raid specific changes, and I received his "Acked-by" for the changes to MD[1]. However I have thus far been unable to attract someone to 'ack/nak' the async_tx api and the changes to drivers/dma/ [2]. Jeff commented on an early revision... I have recently gravitated to Herbert and the crypto directory since async_tx and crypto have some structural similarities [3]. I wouldn't recommend it. It's an ongoing source of bustage frankly, has a habit of getting unpleasantly tangled with git-ioat.patch and afaik is still awaiting a go-ahead from Neil. Sorry, the crypto/Kconfig bustage was a goof on my part as I moved the async_tx files from drivers/dma/, to the top-level directory, and finally to crypto/. Hopefully these recent build breakages I have caused in -mm have not put the series in too negative a light... I was hoping the git-ioat.patch situation would be solved by me rebasing my series on a version of mainline with Chris' changes merged, but his attempts over the past two merge windows were ignored. Should my series wait outside of -mm until git-ioat.patch makes forward progress? Overall, I feel that async_tx is perhaps justifiably receiving the silent treatment because offload engines are not a mainstream occurrence. Currently only people with an Xscale IOP or a PPC 440spe [4] will notice that mainline lacks support for all the features of their platform. I see async_tx as a nod to the embedded space where offload engines act to make up for the absence of multi-Ghz CPUs with streaming SIMD instructions. Herbert's offer is greatly appreciated as it will give guidance to the parts of the series outside of Neil's purview. Regards, Dan [1]: The ack from Neil was in an offlist message for the MD specific portion of the series [2]: I asked DaveM and netdev to take a look at the two patches in the series that change drivers/dma/ and net/core/dev.c since that was the original merge path for I/OAT and dmaengine [3]: async_tx is similar to crypto in that they both provide a library of memory transforms that can in some cases be carried out by hardware. [4]: async_tx has attracted at least one other developer that I know about to write a driver for their engines: http://marc.info/?l=linux-raid=117400143317440=2 - 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: 2.6.22-rc4-mm1
On 6/7/07, Andrew Morton [EMAIL PROTECTED] wrote: On Thu, 7 Jun 2007 17:01:08 +1000 Herbert Xu [EMAIL PROTECTED] wrote: On Thu, Jun 07, 2007 at 08:54:50AM +0200, Jan Engelhardt wrote: /me points at Herbert Andrew would not add options between the menuconfig CRYPTO and the if CRYPTO line... :) Actually this patch is not even in my tree :) uh, OK, sorry. Index: linux-2.6.22-rc4/crypto/Kconfig === --- linux-2.6.22-rc4.orig/crypto/Kconfig +++ linux-2.6.22-rc4/crypto/Kconfig @@ -7,6 +7,8 @@ menuconfig CRYPTO help This option provides the core Cryptographic API. +if CRYPTO + # # Generic algorithms support # @@ -18,8 +20,6 @@ config XOR_BLOCKS # source crypto/async_tx/Kconfig Andrew, do you want me to pick the async_tx stuff up instead? It would be very helpful to have a clear merge path for dmaengine changes and the async offload api. Neil has been extremely helpful reviewing the raid specific changes, and I received his Acked-by for the changes to MD[1]. However I have thus far been unable to attract someone to 'ack/nak' the async_tx api and the changes to drivers/dma/ [2]. Jeff commented on an early revision... I have recently gravitated to Herbert and the crypto directory since async_tx and crypto have some structural similarities [3]. I wouldn't recommend it. It's an ongoing source of bustage frankly, has a habit of getting unpleasantly tangled with git-ioat.patch and afaik is still awaiting a go-ahead from Neil. Sorry, the crypto/Kconfig bustage was a goof on my part as I moved the async_tx files from drivers/dma/, to the top-level directory, and finally to crypto/. Hopefully these recent build breakages I have caused in -mm have not put the series in too negative a light... I was hoping the git-ioat.patch situation would be solved by me rebasing my series on a version of mainline with Chris' changes merged, but his attempts over the past two merge windows were ignored. Should my series wait outside of -mm until git-ioat.patch makes forward progress? Overall, I feel that async_tx is perhaps justifiably receiving the silent treatment because offload engines are not a mainstream occurrence. Currently only people with an Xscale IOP or a PPC 440spe [4] will notice that mainline lacks support for all the features of their platform. I see async_tx as a nod to the embedded space where offload engines act to make up for the absence of multi-Ghz CPUs with streaming SIMD instructions. Herbert's offer is greatly appreciated as it will give guidance to the parts of the series outside of Neil's purview. Regards, Dan [1]: The ack from Neil was in an offlist message for the MD specific portion of the series [2]: I asked DaveM and netdev to take a look at the two patches in the series that change drivers/dma/ and net/core/dev.c since that was the original merge path for I/OAT and dmaengine [3]: async_tx is similar to crypto in that they both provide a library of memory transforms that can in some cases be carried out by hardware. [4]: async_tx has attracted at least one other developer that I know about to write a driver for their engines: http://marc.info/?l=linux-raidm=117400143317440w=2 - 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: 2.6.22-rc4-mm1 -- x86_64 ACPI panic
On Fri, 8 Jun 2007 17:15:45 +0800
"Luming Yu" <[EMAIL PROTECTED]> wrote:
> The only problem known as to the acpi throttling changes in the mm tree
> is a typo ,and the patch to fix it is available here. Please test and
> get results back to me. BTW,the log shows that the acpi-cpufreq.ko has
> problem. Would please also try not to load acpi-cpufreq.
>
> http://www.ussg.iu.edu/hypermail/linux/kernel/0706.0/2509.html
Sigh. Is this some sort of contest to see how many things we can
do wrong in a single patch?
- Include a changelog
- Include Signed-off-by:
- Don't use attachments
- If you _must_ use attachments, use text/plain, not application/octet-stream
- Format code to remain within 80 columns.
- Don't do "if(". Do "if ("
Oh well. Good to hear that the oops got fixed, thanks.
From: "Luming Yu" <[EMAIL PROTECTED]>
Cc: Len Brown <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/acpi/processor_throttling.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff -puN
drivers/acpi/processor_throttling.c~acpi-fix-oops-in-acpi_processor_throttling_seq_show
drivers/acpi/processor_throttling.c
---
a/drivers/acpi/processor_throttling.c~acpi-fix-oops-in-acpi_processor_throttling_seq_show
+++ a/drivers/acpi/processor_throttling.c
@@ -656,18 +656,20 @@ static int acpi_processor_throttling_seq
pr->throttling.state_count - 1);
seq_puts(seq, "states:\n");
- if (acpi_processor_get_throttling == acpi_processor_get_throttling_fadt)
+ if (pr->throttling.acpi_processor_get_throttling ==
+ acpi_processor_get_throttling_fadt) {
for (i = 0; i < pr->throttling.state_count; i++)
seq_printf(seq, " %cT%d: %02d%%\n",
(i == pr->throttling.state ? '*' : ' '), i,
(pr->throttling.states[i].performance ? pr->
throttling.states[i].performance / 10 : 0));
- else
+ } else {
for (i = 0; i < pr->throttling.state_count; i++)
seq_printf(seq, " %cT%d: %02d%%\n",
(i == pr->throttling.state ? '*' : ' '), i,
(int)pr->throttling.states_tss[i].
freqpercentage);
+ }
end:
return 0;
_
-
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: 2.6.22-rc4-mm1
Kay Sievers wrote: Peter, any idea what it could be, that goes wrong on Andrew's box, or how to look for what exactly is going wrong? http://userweb.kernel.org/~akpm/s5000552.jpg Seems that yellowdog uses RH's nash. Yeah, but a /really/ old version -- 4.2.11 is from May 2005 :/ . I feel I should point out that that version IS using udev, but just like mkinitrd and nash, the udev there is probably just as old. At the same time, that does make it an excellent test case for this sort of situation. Andrew, is there any chance you can put that initrd.img somewhere that I can download it? That'd really help me to figure out what's going on, as the minutia of our initrds from 2005 have faded a bit in my memory. -- Peter - 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: 2.6.22-rc4-mm1
On Fri, 2007-06-08 at 08:51 -0700, Greg KH wrote: > On Fri, Jun 08, 2007 at 12:31:18AM -0700, Andrew Morton wrote: > > On Thu, 7 Jun 2007 09:15:25 -0700 Greg KH <[EMAIL PROTECTED]> wrote: > > > > > On Thu, Jun 07, 2007 at 09:06:32AM -0700, Andrew Morton wrote: > > > > On Thu, 7 Jun 2007 08:59:53 -0700 Greg KH <[EMAIL PROTECTED]> wrote: > > > > > > > > > On Thu, Jun 07, 2007 at 08:52:00AM -0700, Andrew Morton wrote: > > > > > > On Thu, 7 Jun 2007 08:43:42 -0700 Greg KH <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > Fixed in mkinitrd-6.0.9-6 , which I'll build now and push to > > > > > > > > updates-testing. Thanks for getting my attention here. > > > > > > > > > > > > > > Great, Andrew, can you please reenable the block-device patch > > > > > > > that is in > > > > > > > my tree now that the problem has been solved? > > > > > > > > > > > > I think we're screwed, aren't we? Everyone needs to upgrade > > > > > > mkinitrd to be > > > > > > able to boot the kernel? Not viable :( > > > > > > > > > > > > For example, what about my two-year-old yellowdog machine? > > > > > > > > > > Enable CONFIG_SYSFS_DEPRECATED and it should all work just fine. > > > > > That's > > > > > what Michal said worked for him. > > > > > > > > > > > > > Actually, it _was_ enabled. > > > > > > > > Ho hum, I'll have a poke at it this evening. > > > > > > Yeah, that sounds odd, it should have worked. > > > > yup, yellowdog 4.1 on a mac g5: > > > > gregkh-driver-block-device.patch applied, CONFIG_SYSFS_DEPRECATED=y: > > http://userweb.kernel.org/~akpm/s5000552.jpg > > Ugh. > > Kay, any thoughts? Does switchroot need to have the --movedev option > removed for some reason? Hmm, no idea, /sys/block should not have changed with CONFIG_SYSFS_DEPRECATED=y. And it works fine for Michal and FC7. Alan Stern mentioned the --movedev option with its customized initramfs, or did other people report something similar? Peter, any idea what it could be, that goes wrong on Andrew's box, or how to look for what exactly is going wrong? http://userweb.kernel.org/~akpm/s5000552.jpg Seems that yellowdog uses RH's nash. Thanks, Kay - 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: 2.6.22-rc4-mm1
On Fri, Jun 08, 2007 at 08:50:27AM -0700, Greg KH wrote: > On Fri, Jun 08, 2007 at 11:33:38AM -0400, [EMAIL PROTECTED] wrote: > > On Thu, 07 Jun 2007 16:09:04 PDT, Greg KH said: > > > If CONFIG_SYSFS_DEPRECATED everything should work just fine with all old > > > initrd scripts. It's only if you enable that option (which is enabled > > > by default) that you need to ensure that your distro has the latest > > > functionality so that everything works properly. > > > > Can somebody document what an initrd has to do differently? Some of us > > run with initrd's not created by mkinitrd. > > So I'm guessing that you wrote your own initrd? > > The main issue is that /sys/block/ is now full of symlinks, not real > directories, if CONFIG_SYSFS_DEPRECATED is not enabled. That means that > any program that was doing stat() should be doing lstat() for the block > directory to work on all instances (remember, whenever looking for a > directory or a file in sysfs, it could be either a real file/directory > or a symlink, you should not care either way.) Oops, sorry about that, it should be the other way around, stat(), not lstat(). 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: 2.6.22-rc4-mm1
On Fri, 2007-06-08 at 11:33 -0400, [EMAIL PROTECTED] wrote: > On Thu, 07 Jun 2007 16:09:04 PDT, Greg KH said: > > If CONFIG_SYSFS_DEPRECATED everything should work just fine with all old > > initrd scripts. It's only if you enable that option (which is enabled > > by default) that you need to ensure that your distro has the latest > > functionality so that everything works properly. > > Can somebody document what an initrd has to do differently? Some of us > run with initrd's not created by mkinitrd. You should be fine if you don't explicitly distinguish between symlinks and directories. Or just look what almost everybody is doing in initramfs, Debian, Gentoo, Ubuntu, SUSE, ..., all use uevent-driven udev bootup there, and it just works without caring about anything in sysfs or weird timing issues. Kay - 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: 2.6.22-rc4-mm1
On Fri, Jun 08, 2007 at 12:31:18AM -0700, Andrew Morton wrote: > On Thu, 7 Jun 2007 09:15:25 -0700 Greg KH <[EMAIL PROTECTED]> wrote: > > > On Thu, Jun 07, 2007 at 09:06:32AM -0700, Andrew Morton wrote: > > > On Thu, 7 Jun 2007 08:59:53 -0700 Greg KH <[EMAIL PROTECTED]> wrote: > > > > > > > On Thu, Jun 07, 2007 at 08:52:00AM -0700, Andrew Morton wrote: > > > > > On Thu, 7 Jun 2007 08:43:42 -0700 Greg KH <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > Fixed in mkinitrd-6.0.9-6 , which I'll build now and push to > > > > > > > updates-testing. Thanks for getting my attention here. > > > > > > > > > > > > Great, Andrew, can you please reenable the block-device patch that > > > > > > is in > > > > > > my tree now that the problem has been solved? > > > > > > > > > > I think we're screwed, aren't we? Everyone needs to upgrade mkinitrd > > > > > to be > > > > > able to boot the kernel? Not viable :( > > > > > > > > > > For example, what about my two-year-old yellowdog machine? > > > > > > > > Enable CONFIG_SYSFS_DEPRECATED and it should all work just fine. That's > > > > what Michal said worked for him. > > > > > > > > > > Actually, it _was_ enabled. > > > > > > Ho hum, I'll have a poke at it this evening. > > > > Yeah, that sounds odd, it should have worked. > > yup, yellowdog 4.1 on a mac g5: > > gregkh-driver-block-device.patch applied, CONFIG_SYSFS_DEPRECATED=y: > http://userweb.kernel.org/~akpm/s5000552.jpg Ugh. Kay, any thoughts? Does switchroot need to have the --movedev option removed for some reason? 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: 2.6.22-rc4-mm1
On Fri, Jun 08, 2007 at 11:33:38AM -0400, [EMAIL PROTECTED] wrote: > On Thu, 07 Jun 2007 16:09:04 PDT, Greg KH said: > > If CONFIG_SYSFS_DEPRECATED everything should work just fine with all old > > initrd scripts. It's only if you enable that option (which is enabled > > by default) that you need to ensure that your distro has the latest > > functionality so that everything works properly. > > Can somebody document what an initrd has to do differently? Some of us > run with initrd's not created by mkinitrd. So I'm guessing that you wrote your own initrd? The main issue is that /sys/block/ is now full of symlinks, not real directories, if CONFIG_SYSFS_DEPRECATED is not enabled. That means that any program that was doing stat() should be doing lstat() for the block directory to work on all instances (remember, whenever looking for a directory or a file in sysfs, it could be either a real file/directory or a symlink, you should not care either way.) People have also reported that for some reason, removing the '--movedev' argument to switchroot is also needed, but that might just be a Fedora 7 specific thing, I'm not quite sure. See the post from Alan Stern on lkml with the subject: Re: [RFC PATCH] /sys/block -> /sys/class/block (Fedora 3 & 4 testers wanted) for more details on that. Hope this helps, 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: 2.6.22-rc4-mm1
On Thu, 07 Jun 2007 16:09:04 PDT, Greg KH said: > If CONFIG_SYSFS_DEPRECATED everything should work just fine with all old > initrd scripts. It's only if you enable that option (which is enabled > by default) that you need to ensure that your distro has the latest > functionality so that everything works properly. Can somebody document what an initrd has to do differently? Some of us run with initrd's not created by mkinitrd. pgpSDJpa377Wm.pgp Description: PGP signature
Re: 2.6.22-rc4-mm1 -- x86_64 ACPI panic
The only problem known as to the acpi throttling changes in the mm tree is a typo ,and the patch to fix it is available here. Please test and get results back to me. BTW,the log shows that the acpi-cpufreq.ko has problem. Would please also try not to load acpi-cpufreq. http://www.ussg.iu.edu/hypermail/linux/kernel/0706.0/2509.html On 6/7/07, Andrew Morton <[EMAIL PROTECTED]> wrote: On Wed, 06 Jun 2007 15:00:17 +0100 Andy Whitcroft <[EMAIL PROTECTED]> wrote: > Getting this on a bigger x86_64 (bl6-13): > > Unable to handle kernel NULL pointer dereference at RIP: > [] acpi_processor_throttling_seq_show+0xa7/0xd6 > PGD 2d77067 PUD 34c3067 PMD 0 > Oops: [1] SMP > CPU 3 > Modules linked in: video output button battery asus_acpi ac lp > parport_pc parport floppy nvram amd_rng rng_core i2c_amd756 i2c_core > Pid: 1634, comm: head Not tainted 2.6.22-rc4-mm1-autokern1 #1 > RIP: 0010:[] [] > acpi_processor_throttling_seq_show+0xa7/0xd6 > RSP: 0018:810003c9de48 EFLAGS: 00010246 > RAX: 0020 RBX: 8100029e7800 RCX: > RDX: 002a RSI: 805993e4 RDI: 810002d714c0 > RBP: 810002d714c0 R08: 810003f82051 R09: 810002d714c0 > R10: R11: R12: > R13: R14: R15: 7fff64fd2b90 > FS: 2b3545aec6f0() GS:810001683a40() knlGS: > CS: 0010 DS: ES: CR0: 8005003b > CR2: CR3: 03966000 CR4: 06e0 > DR0: DR1: DR2: > DR3: DR6: 0ff0 DR7: 0400 > Process head (pid: 1634, threadinfo 810003c9c000, task 810001c8c810) > Stack: 00d0 810002d714c0 0001 0001 > 2000 802ab6eb 810003c9df50 810002915d00 > 810002d714f0 810002fa2000 fffb > Call Trace: > [] seq_read+0x105/0x28e > [] seq_read+0x0/0x28e > [] proc_reg_read+0x80/0x9a > [] vfs_read+0xcb/0x153 > [] sys_read+0x45/0x6e > [] system_call+0x7e/0x83 > > > Code: 45 8b 44 0d 00 44 89 e1 0f 45 d0 31 c0 49 ff c4 49 83 c5 28 > RIP [] acpi_processor_throttling_seq_show+0xa7/0xd6 > RSP > CR2: > FATAL: Error inserting acpi_cpufreq > (/lib/modules/2.6.22-rc4-mm1-autokern1/kernel/arch/x86_64/kernel/cpufreq/acpi-cpufreq.ko): > No such device Was the oops at modprobe time? If so, it seems weird that acpi_processor_throttling_seq_show() would be getting run at that stage. (The oops trace is supposed to show the oopsing process's task_struct.comm[], but it isn't shown here?) Anyway, there are extensive changes in there added by git-acpi.patch. I suppose we can try to limp along with the below, but it'll probably just oops later on. --- a/drivers/acpi/processor_throttling.c~git-acpi-disable-acpi_processor_throttling_seq_show +++ a/drivers/acpi/processor_throttling.c @@ -648,6 +648,9 @@ static int acpi_processor_throttling_seq goto end; } + seq_puts(seq, "acpi_processor_throttling_seq_show() is busted\n"); + goto end; + seq_printf(seq, "state count: %d\n" "active state:T%d\n" "state available: T%d to T%d\n", _ - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - 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: 2.6.22-rc4-mm1
On Thu, 7 Jun 2007 09:15:25 -0700 Greg KH <[EMAIL PROTECTED]> wrote: > On Thu, Jun 07, 2007 at 09:06:32AM -0700, Andrew Morton wrote: > > On Thu, 7 Jun 2007 08:59:53 -0700 Greg KH <[EMAIL PROTECTED]> wrote: > > > > > On Thu, Jun 07, 2007 at 08:52:00AM -0700, Andrew Morton wrote: > > > > On Thu, 7 Jun 2007 08:43:42 -0700 Greg KH <[EMAIL PROTECTED]> wrote: > > > > > > > > > > Fixed in mkinitrd-6.0.9-6 , which I'll build now and push to > > > > > > updates-testing. Thanks for getting my attention here. > > > > > > > > > > Great, Andrew, can you please reenable the block-device patch that is > > > > > in > > > > > my tree now that the problem has been solved? > > > > > > > > I think we're screwed, aren't we? Everyone needs to upgrade mkinitrd > > > > to be > > > > able to boot the kernel? Not viable :( > > > > > > > > For example, what about my two-year-old yellowdog machine? > > > > > > Enable CONFIG_SYSFS_DEPRECATED and it should all work just fine. That's > > > what Michal said worked for him. > > > > > > > Actually, it _was_ enabled. > > > > Ho hum, I'll have a poke at it this evening. > > Yeah, that sounds odd, it should have worked. yup, yellowdog 4.1 on a mac g5: gregkh-driver-block-device.patch applied, CONFIG_SYSFS_DEPRECATED=y: http://userweb.kernel.org/~akpm/s5000552.jpg gregkh-driver-block-device.patch applied, CONFIG_SYSFS_DEPRECATED=n: Can't open /dev/sdb6 (root partition) gregkh-driver-block-device.patch not applied, CONFIG_SYSFS_DEPRECATED=y: Happy camper gregkh-driver-block-device.patch not applied, CONFIG_SYSFS_DEPRECATED=n: Still happy - 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: 2.6.22-rc4-mm1 - 'lvm vgscan' busticated again...
[EMAIL PROTECTED] wrote: > On Thu, 07 Jun 2007 15:44:56 +0900, Tejun Heo said: >> [EMAIL PROTECTED] wrote: >>> On Wed, 06 Jun 2007 02:07:37 PDT, Andrew Morton said: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2 > .6.22-rc4-mm1/ >>> This one died a horrid death at boot time - console log indicates it found > the >>> hard drive OK, found the 2 partitions on it. But when the initrd ran a >>> 'lvm vgscan', it didn't find the LVM2 space on /dev/sda2, so it panic'ed wh > en >>> it fell off the end of the initrd because the root= wasn't there. >>> >>> My first guess for blame: >>> >>> gregkh-driver-sysfs-allocate-inode-number-using-ida.patch >>> >>> as that's awfully similar to >>> gregkh-driver-sysfs-fix-i_ino-handling-in-sysfs.patch >>> that broke 'lvm vgscan' for me in the same way on 21-rc7-mm[12]. >>> >>> I'll hopefully get a chance to revert that one and test later today - a >>> quick >>> 'patch -p1 -R --dry-run' shows a number of conflicts that will need >>> hand-fixing >>> at the very least. >> Did rc3-mm1 work? Can you find out the first broken -mm? > > 21-rc5-mm2 worked, -rc6-mm* were busticated for other reasons on my laptop, > 21-rc7-mm[12] were broken, 21-mm1 through 21-rc3-mm1 worked, -rc4-mm1 broke, > and -rc4-mm2 works. I could bisect through -rc4-mm1 if it's deemed useful, > Andrew just pushed -mm2 before I had a chance. Thanks. The offending patch was gregkh-driver-block-device Which is pulled from -mm2. Jiri Slaby reports that turning on SYSFS_DEPRECATED fixes the problem. Thanks. -- tejun - 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: 2.6.22-rc4-mm1 - 'lvm vgscan' busticated again...
[EMAIL PROTECTED] wrote: On Thu, 07 Jun 2007 15:44:56 +0900, Tejun Heo said: [EMAIL PROTECTED] wrote: On Wed, 06 Jun 2007 02:07:37 PDT, Andrew Morton said: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2 .6.22-rc4-mm1/ This one died a horrid death at boot time - console log indicates it found the hard drive OK, found the 2 partitions on it. But when the initrd ran a 'lvm vgscan', it didn't find the LVM2 space on /dev/sda2, so it panic'ed wh en it fell off the end of the initrd because the root= wasn't there. My first guess for blame: gregkh-driver-sysfs-allocate-inode-number-using-ida.patch as that's awfully similar to gregkh-driver-sysfs-fix-i_ino-handling-in-sysfs.patch that broke 'lvm vgscan' for me in the same way on 21-rc7-mm[12]. I'll hopefully get a chance to revert that one and test later today - a quick 'patch -p1 -R --dry-run' shows a number of conflicts that will need hand-fixing at the very least. Did rc3-mm1 work? Can you find out the first broken -mm? 21-rc5-mm2 worked, -rc6-mm* were busticated for other reasons on my laptop, 21-rc7-mm[12] were broken, 21-mm1 through 21-rc3-mm1 worked, -rc4-mm1 broke, and -rc4-mm2 works. I could bisect through -rc4-mm1 if it's deemed useful, Andrew just pushed -mm2 before I had a chance. Thanks. The offending patch was gregkh-driver-block-device Which is pulled from -mm2. Jiri Slaby reports that turning on SYSFS_DEPRECATED fixes the problem. Thanks. -- tejun - 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: 2.6.22-rc4-mm1
On Thu, 7 Jun 2007 09:15:25 -0700 Greg KH [EMAIL PROTECTED] wrote: On Thu, Jun 07, 2007 at 09:06:32AM -0700, Andrew Morton wrote: On Thu, 7 Jun 2007 08:59:53 -0700 Greg KH [EMAIL PROTECTED] wrote: On Thu, Jun 07, 2007 at 08:52:00AM -0700, Andrew Morton wrote: On Thu, 7 Jun 2007 08:43:42 -0700 Greg KH [EMAIL PROTECTED] wrote: Fixed in mkinitrd-6.0.9-6 , which I'll build now and push to updates-testing. Thanks for getting my attention here. Great, Andrew, can you please reenable the block-device patch that is in my tree now that the problem has been solved? I think we're screwed, aren't we? Everyone needs to upgrade mkinitrd to be able to boot the kernel? Not viable :( For example, what about my two-year-old yellowdog machine? Enable CONFIG_SYSFS_DEPRECATED and it should all work just fine. That's what Michal said worked for him. Actually, it _was_ enabled. Ho hum, I'll have a poke at it this evening. Yeah, that sounds odd, it should have worked. yup, yellowdog 4.1 on a mac g5: gregkh-driver-block-device.patch applied, CONFIG_SYSFS_DEPRECATED=y: http://userweb.kernel.org/~akpm/s5000552.jpg gregkh-driver-block-device.patch applied, CONFIG_SYSFS_DEPRECATED=n: Can't open /dev/sdb6 (root partition) gregkh-driver-block-device.patch not applied, CONFIG_SYSFS_DEPRECATED=y: Happy camper gregkh-driver-block-device.patch not applied, CONFIG_SYSFS_DEPRECATED=n: Still happy - 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: 2.6.22-rc4-mm1 -- x86_64 ACPI panic
The only problem known as to the acpi throttling changes in the mm tree is a typo ,and the patch to fix it is available here. Please test and get results back to me. BTW,the log shows that the acpi-cpufreq.ko has problem. Would please also try not to load acpi-cpufreq. http://www.ussg.iu.edu/hypermail/linux/kernel/0706.0/2509.html On 6/7/07, Andrew Morton [EMAIL PROTECTED] wrote: On Wed, 06 Jun 2007 15:00:17 +0100 Andy Whitcroft [EMAIL PROTECTED] wrote: Getting this on a bigger x86_64 (bl6-13): Unable to handle kernel NULL pointer dereference at RIP: [8037898b] acpi_processor_throttling_seq_show+0xa7/0xd6 PGD 2d77067 PUD 34c3067 PMD 0 Oops: [1] SMP CPU 3 Modules linked in: video output button battery asus_acpi ac lp parport_pc parport floppy nvram amd_rng rng_core i2c_amd756 i2c_core Pid: 1634, comm: head Not tainted 2.6.22-rc4-mm1-autokern1 #1 RIP: 0010:[8037898b] [8037898b] acpi_processor_throttling_seq_show+0xa7/0xd6 RSP: 0018:810003c9de48 EFLAGS: 00010246 RAX: 0020 RBX: 8100029e7800 RCX: RDX: 002a RSI: 805993e4 RDI: 810002d714c0 RBP: 810002d714c0 R08: 810003f82051 R09: 810002d714c0 R10: R11: R12: R13: R14: R15: 7fff64fd2b90 FS: 2b3545aec6f0() GS:810001683a40() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: CR3: 03966000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process head (pid: 1634, threadinfo 810003c9c000, task 810001c8c810) Stack: 00d0 810002d714c0 0001 0001 2000 802ab6eb 810003c9df50 810002915d00 810002d714f0 810002fa2000 fffb Call Trace: [802ab6eb] seq_read+0x105/0x28e [802ab5e6] seq_read+0x0/0x28e [802cd085] proc_reg_read+0x80/0x9a [802925a7] vfs_read+0xcb/0x153 [80292943] sys_read+0x45/0x6e [8020bc5e] system_call+0x7e/0x83 Code: 45 8b 44 0d 00 44 89 e1 0f 45 d0 31 c0 49 ff c4 49 83 c5 28 RIP [8037898b] acpi_processor_throttling_seq_show+0xa7/0xd6 RSP 810003c9de48 CR2: FATAL: Error inserting acpi_cpufreq (/lib/modules/2.6.22-rc4-mm1-autokern1/kernel/arch/x86_64/kernel/cpufreq/acpi-cpufreq.ko): No such device Was the oops at modprobe time? If so, it seems weird that acpi_processor_throttling_seq_show() would be getting run at that stage. (The oops trace is supposed to show the oopsing process's task_struct.comm[], but it isn't shown here?) Anyway, there are extensive changes in there added by git-acpi.patch. I suppose we can try to limp along with the below, but it'll probably just oops later on. --- a/drivers/acpi/processor_throttling.c~git-acpi-disable-acpi_processor_throttling_seq_show +++ a/drivers/acpi/processor_throttling.c @@ -648,6 +648,9 @@ static int acpi_processor_throttling_seq goto end; } + seq_puts(seq, acpi_processor_throttling_seq_show() is busted\n); + goto end; + seq_printf(seq, state count: %d\n active state:T%d\n state available: T%d to T%d\n, _ - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - 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: 2.6.22-rc4-mm1
On Fri, Jun 08, 2007 at 11:33:38AM -0400, [EMAIL PROTECTED] wrote: On Thu, 07 Jun 2007 16:09:04 PDT, Greg KH said: If CONFIG_SYSFS_DEPRECATED everything should work just fine with all old initrd scripts. It's only if you enable that option (which is enabled by default) that you need to ensure that your distro has the latest functionality so that everything works properly. Can somebody document what an initrd has to do differently? Some of us run with initrd's not created by mkinitrd. So I'm guessing that you wrote your own initrd? The main issue is that /sys/block/ is now full of symlinks, not real directories, if CONFIG_SYSFS_DEPRECATED is not enabled. That means that any program that was doing stat() should be doing lstat() for the block directory to work on all instances (remember, whenever looking for a directory or a file in sysfs, it could be either a real file/directory or a symlink, you should not care either way.) People have also reported that for some reason, removing the '--movedev' argument to switchroot is also needed, but that might just be a Fedora 7 specific thing, I'm not quite sure. See the post from Alan Stern on lkml with the subject: Re: [RFC PATCH] /sys/block - /sys/class/block (Fedora 3 4 testers wanted) for more details on that. Hope this helps, 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: 2.6.22-rc4-mm1
On Fri, Jun 08, 2007 at 12:31:18AM -0700, Andrew Morton wrote: On Thu, 7 Jun 2007 09:15:25 -0700 Greg KH [EMAIL PROTECTED] wrote: On Thu, Jun 07, 2007 at 09:06:32AM -0700, Andrew Morton wrote: On Thu, 7 Jun 2007 08:59:53 -0700 Greg KH [EMAIL PROTECTED] wrote: On Thu, Jun 07, 2007 at 08:52:00AM -0700, Andrew Morton wrote: On Thu, 7 Jun 2007 08:43:42 -0700 Greg KH [EMAIL PROTECTED] wrote: Fixed in mkinitrd-6.0.9-6 , which I'll build now and push to updates-testing. Thanks for getting my attention here. Great, Andrew, can you please reenable the block-device patch that is in my tree now that the problem has been solved? I think we're screwed, aren't we? Everyone needs to upgrade mkinitrd to be able to boot the kernel? Not viable :( For example, what about my two-year-old yellowdog machine? Enable CONFIG_SYSFS_DEPRECATED and it should all work just fine. That's what Michal said worked for him. Actually, it _was_ enabled. Ho hum, I'll have a poke at it this evening. Yeah, that sounds odd, it should have worked. yup, yellowdog 4.1 on a mac g5: gregkh-driver-block-device.patch applied, CONFIG_SYSFS_DEPRECATED=y: http://userweb.kernel.org/~akpm/s5000552.jpg Ugh. Kay, any thoughts? Does switchroot need to have the --movedev option removed for some reason? 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: 2.6.22-rc4-mm1
On Thu, 07 Jun 2007 16:09:04 PDT, Greg KH said: If CONFIG_SYSFS_DEPRECATED everything should work just fine with all old initrd scripts. It's only if you enable that option (which is enabled by default) that you need to ensure that your distro has the latest functionality so that everything works properly. Can somebody document what an initrd has to do differently? Some of us run with initrd's not created by mkinitrd. pgpSDJpa377Wm.pgp Description: PGP signature
Re: 2.6.22-rc4-mm1
On Fri, 2007-06-08 at 11:33 -0400, [EMAIL PROTECTED] wrote: On Thu, 07 Jun 2007 16:09:04 PDT, Greg KH said: If CONFIG_SYSFS_DEPRECATED everything should work just fine with all old initrd scripts. It's only if you enable that option (which is enabled by default) that you need to ensure that your distro has the latest functionality so that everything works properly. Can somebody document what an initrd has to do differently? Some of us run with initrd's not created by mkinitrd. You should be fine if you don't explicitly distinguish between symlinks and directories. Or just look what almost everybody is doing in initramfs, Debian, Gentoo, Ubuntu, SUSE, ..., all use uevent-driven udev bootup there, and it just works without caring about anything in sysfs or weird timing issues. Kay - 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: 2.6.22-rc4-mm1
On Fri, Jun 08, 2007 at 08:50:27AM -0700, Greg KH wrote: On Fri, Jun 08, 2007 at 11:33:38AM -0400, [EMAIL PROTECTED] wrote: On Thu, 07 Jun 2007 16:09:04 PDT, Greg KH said: If CONFIG_SYSFS_DEPRECATED everything should work just fine with all old initrd scripts. It's only if you enable that option (which is enabled by default) that you need to ensure that your distro has the latest functionality so that everything works properly. Can somebody document what an initrd has to do differently? Some of us run with initrd's not created by mkinitrd. So I'm guessing that you wrote your own initrd? The main issue is that /sys/block/ is now full of symlinks, not real directories, if CONFIG_SYSFS_DEPRECATED is not enabled. That means that any program that was doing stat() should be doing lstat() for the block directory to work on all instances (remember, whenever looking for a directory or a file in sysfs, it could be either a real file/directory or a symlink, you should not care either way.) Oops, sorry about that, it should be the other way around, stat(), not lstat(). 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: 2.6.22-rc4-mm1
On Fri, 2007-06-08 at 08:51 -0700, Greg KH wrote: On Fri, Jun 08, 2007 at 12:31:18AM -0700, Andrew Morton wrote: On Thu, 7 Jun 2007 09:15:25 -0700 Greg KH [EMAIL PROTECTED] wrote: On Thu, Jun 07, 2007 at 09:06:32AM -0700, Andrew Morton wrote: On Thu, 7 Jun 2007 08:59:53 -0700 Greg KH [EMAIL PROTECTED] wrote: On Thu, Jun 07, 2007 at 08:52:00AM -0700, Andrew Morton wrote: On Thu, 7 Jun 2007 08:43:42 -0700 Greg KH [EMAIL PROTECTED] wrote: Fixed in mkinitrd-6.0.9-6 , which I'll build now and push to updates-testing. Thanks for getting my attention here. Great, Andrew, can you please reenable the block-device patch that is in my tree now that the problem has been solved? I think we're screwed, aren't we? Everyone needs to upgrade mkinitrd to be able to boot the kernel? Not viable :( For example, what about my two-year-old yellowdog machine? Enable CONFIG_SYSFS_DEPRECATED and it should all work just fine. That's what Michal said worked for him. Actually, it _was_ enabled. Ho hum, I'll have a poke at it this evening. Yeah, that sounds odd, it should have worked. yup, yellowdog 4.1 on a mac g5: gregkh-driver-block-device.patch applied, CONFIG_SYSFS_DEPRECATED=y: http://userweb.kernel.org/~akpm/s5000552.jpg Ugh. Kay, any thoughts? Does switchroot need to have the --movedev option removed for some reason? Hmm, no idea, /sys/block should not have changed with CONFIG_SYSFS_DEPRECATED=y. And it works fine for Michal and FC7. Alan Stern mentioned the --movedev option with its customized initramfs, or did other people report something similar? Peter, any idea what it could be, that goes wrong on Andrew's box, or how to look for what exactly is going wrong? http://userweb.kernel.org/~akpm/s5000552.jpg Seems that yellowdog uses RH's nash. Thanks, Kay - 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: 2.6.22-rc4-mm1
Kay Sievers wrote: Peter, any idea what it could be, that goes wrong on Andrew's box, or how to look for what exactly is going wrong? http://userweb.kernel.org/~akpm/s5000552.jpg Seems that yellowdog uses RH's nash. Yeah, but a /really/ old version -- 4.2.11 is from May 2005 :/ . I feel I should point out that that version IS using udev, but just like mkinitrd and nash, the udev there is probably just as old. At the same time, that does make it an excellent test case for this sort of situation. Andrew, is there any chance you can put that initrd.img somewhere that I can download it? That'd really help me to figure out what's going on, as the minutia of our initrds from 2005 have faded a bit in my memory. -- Peter - 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: 2.6.22-rc4-mm1 -- x86_64 ACPI panic
On Fri, 8 Jun 2007 17:15:45 +0800
Luming Yu [EMAIL PROTECTED] wrote:
The only problem known as to the acpi throttling changes in the mm tree
is a typo ,and the patch to fix it is available here. Please test and
get results back to me. BTW,the log shows that the acpi-cpufreq.ko has
problem. Would please also try not to load acpi-cpufreq.
http://www.ussg.iu.edu/hypermail/linux/kernel/0706.0/2509.html
Sigh. Is this some sort of contest to see how many things we can
do wrong in a single patch?
- Include a changelog
- Include Signed-off-by:
- Don't use attachments
- If you _must_ use attachments, use text/plain, not application/octet-stream
- Format code to remain within 80 columns.
- Don't do if(. Do if (
Oh well. Good to hear that the oops got fixed, thanks.
From: Luming Yu [EMAIL PROTECTED]
Cc: Len Brown [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/acpi/processor_throttling.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff -puN
drivers/acpi/processor_throttling.c~acpi-fix-oops-in-acpi_processor_throttling_seq_show
drivers/acpi/processor_throttling.c
---
a/drivers/acpi/processor_throttling.c~acpi-fix-oops-in-acpi_processor_throttling_seq_show
+++ a/drivers/acpi/processor_throttling.c
@@ -656,18 +656,20 @@ static int acpi_processor_throttling_seq
pr-throttling.state_count - 1);
seq_puts(seq, states:\n);
- if (acpi_processor_get_throttling == acpi_processor_get_throttling_fadt)
+ if (pr-throttling.acpi_processor_get_throttling ==
+ acpi_processor_get_throttling_fadt) {
for (i = 0; i pr-throttling.state_count; i++)
seq_printf(seq,%cT%d: %02d%%\n,
(i == pr-throttling.state ? '*' : ' '), i,
(pr-throttling.states[i].performance ? pr-
throttling.states[i].performance / 10 : 0));
- else
+ } else {
for (i = 0; i pr-throttling.state_count; i++)
seq_printf(seq,%cT%d: %02d%%\n,
(i == pr-throttling.state ? '*' : ' '), i,
(int)pr-throttling.states_tss[i].
freqpercentage);
+ }
end:
return 0;
_
-
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: 2.6.22-rc4-mm1
On Thu, Jun 07, 2007 at 11:59:16AM -0500, Matt Mackall wrote: >On Fri, Jun 08, 2007 at 12:39:30AM +0800, WANG Cong wrote: >> >Ketchup doesn't even look inside patches, and patch doesn't invent >> >names, so something in the bzip2 -> patch(1) -> filesystem chain got >> >corrupted. Probably not bzip2, as it has CRCs. >> > >> >> Do you mean ketchup doesn't do anything if a file is corrupted? > >Ketchup never even sees the filenames. It just calls bzip2 | patch. So >it can't be responsible for damaging the filename. > >> >Do you have ECC memory? >> >> No. Do you mean it's an error of my RAM? I have never met such things before, >> how often does such kind of things happen? May be less often than a bug in >> a stable kernel? > >The best studies I've seen suggest so-called "soft errors" in DRAM >happen at a rate of once a week to once a day per gigabyte of RAM at >sea-level. It's unknown how many of these errors manifest by visibly >corrupting data, but it wouldn't be surprising if it were >significantly less than 10%. But ECC is definitely not just for the >paranoid! > >So if I were to rank the reliability of everything, it'd look >something like this, highest to lowest: > > bzip: simple, stable and heavily-used codebase, built-in safeguards like CRC > patch: simple, stable, heavily-used, limited detection of input errors > CPU: heavily used, very low non-catastrophic failure rate > disk: heavily used, CRC on cable, ECC on disk > kernel: complex, rapidly-changing, but heavily-used > Non-ECC DRAM: significant known transient failure rate > >When the error rate for the kernel approaches that of DRAM, it gets >very hard to assign blame. > >(And of course, there's the user, who tends to be near the bottom of >this range, but I'll let you judge that.) Good explanation! Thanks! That the RAM error occurs so often really surprises me. I think it might be RAM's fault, because, at least, it's less reproduceable than a bug in a stable kernel. Regards! - 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: 2.6.22-rc4-mm1
On Thu, 7 Jun 2007 08:34:58 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > > I assume the above is your code - it's not in the tree? > Ah, that code was disappeared in -mm2. But it informed me that I should consider memory unplug v.s. sys_mremap case... Thanks, anyway. -Kame - 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: 2.6.22-rc4-mm1
On Thu, Jun 07, 2007 at 11:32:58PM +0100, Alan Cox wrote: > > Ah, but the installer doesn't matter until you do a Fedora 8 release, > > right? This is just for people who want to run their own kernel on an > > already-set-up Fedora machine. > > People can and do roll updated install images because you get systems > that aren't supported by the released CD boot image. The installer/initrd > etc shouldn't keep getting broken by these kind of changes, its about > time that all the sysfs type breakage causing patches simply got > rejected, like such patches would in every other subsystem. > > Yes it might cause a little pain, yes someone might have to tweak sysfs a > bit to keep compatibility and decouple the external and internal view a > bit - Matthew and others pointed out this problem several years ago and > predicted the current state of affairs, so its had a lot of time to get > fixed. If CONFIG_SYSFS_DEPRECATED everything should work just fine with all old initrd scripts. It's only if you enable that option (which is enabled by default) that you need to ensure that your distro has the latest functionality so that everything works properly. So, we should be fine here. The distros that are up to date, and the users of them, can disable the option. All others need to keep it on. 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: 2.6.22-rc4-mm1
On Thu, Jun 07, 2007 at 05:00:41PM -0400, Peter Jones wrote: > Greg KH wrote: > > On Thu, Jun 07, 2007 at 02:48:05PM -0400, Bill Nottingham wrote: > >> Greg KH ([EMAIL PROTECTED]) said: > >>> There are a number of distros out there right now who can support that > >>> option disabled. I'm pretty sure they are the following right now: > >>> Gentoo unstable (actually stable works now for me, but I'm not > >>>going to guarantee it just yet...) > >>> Debian unstable (again stable might work, but I have not heard > >>>any reports from testers.) > >>> openSUSE FACTORY (the 10.3 alpha releases) > >>> > >>> and now it sounds like Red Hat rawhide will also work properly. > >> I suspect while it will work for mkinitrd, the installer will not > >> work properly. > > Ah, but the installer doesn't matter until you do a Fedora 8 release, > > right? This is just for people who want to run their own kernel on an > > already-set-up Fedora machine. > > Eh, not so sure that's true. It's really kudzu rather than the installer > itself, and that's used by, for example, system-config-network. Ok, then for Fedora 7 users, we should just recommend to keep CONFIG_SYSFS_DEPRECATED enabled if you are using the -mm tree now, or after 2.6.23 is out (which is the earliest I expect this block patch to show up in mainline.) 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: 2.6.22-rc4-mm1
> Ah, but the installer doesn't matter until you do a Fedora 8 release, > right? This is just for people who want to run their own kernel on an > already-set-up Fedora machine. People can and do roll updated install images because you get systems that aren't supported by the released CD boot image. The installer/initrd etc shouldn't keep getting broken by these kind of changes, its about time that all the sysfs type breakage causing patches simply got rejected, like such patches would in every other subsystem. Yes it might cause a little pain, yes someone might have to tweak sysfs a bit to keep compatibility and decouple the external and internal view a bit - Matthew and others pointed out this problem several years ago and predicted the current state of affairs, so its had a lot of time to get fixed. Alan - 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: 2.6.22-rc4-mm1
Greg KH wrote: On Thu, Jun 07, 2007 at 02:48:05PM -0400, Bill Nottingham wrote: Greg KH ([EMAIL PROTECTED]) said: There are a number of distros out there right now who can support that option disabled. I'm pretty sure they are the following right now: Gentoo unstable (actually stable works now for me, but I'm not going to guarantee it just yet...) Debian unstable (again stable might work, but I have not heard any reports from testers.) openSUSE FACTORY (the 10.3 alpha releases) and now it sounds like Red Hat rawhide will also work properly. I suspect while it will work for mkinitrd, the installer will not work properly. Ah, but the installer doesn't matter until you do a Fedora 8 release, right? This is just for people who want to run their own kernel on an already-set-up Fedora machine. Eh, not so sure that's true. It's really kudzu rather than the installer itself, and that's used by, for example, system-config-network. -- Peter - 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: 2.6.22-rc4-mm1 - 'lvm vgscan' busticated again...
On Thu, 07 Jun 2007 15:44:56 +0900, Tejun Heo said: > [EMAIL PROTECTED] wrote: > > On Wed, 06 Jun 2007 02:07:37 PDT, Andrew Morton said: > >> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2 .6.22-rc4-mm1/ > > > > This one died a horrid death at boot time - console log indicates it found the > > hard drive OK, found the 2 partitions on it. But when the initrd ran a > > 'lvm vgscan', it didn't find the LVM2 space on /dev/sda2, so it panic'ed wh en > > it fell off the end of the initrd because the root= wasn't there. > > > > My first guess for blame: > > > > gregkh-driver-sysfs-allocate-inode-number-using-ida.patch > > > > as that's awfully similar to > > gregkh-driver-sysfs-fix-i_ino-handling-in-sysfs.patch > > that broke 'lvm vgscan' for me in the same way on 21-rc7-mm[12]. > > > > I'll hopefully get a chance to revert that one and test later today - a > > quick > > 'patch -p1 -R --dry-run' shows a number of conflicts that will need > > hand-fixing > > at the very least. > > Did rc3-mm1 work? Can you find out the first broken -mm? 21-rc5-mm2 worked, -rc6-mm* were busticated for other reasons on my laptop, 21-rc7-mm[12] were broken, 21-mm1 through 21-rc3-mm1 worked, -rc4-mm1 broke, and -rc4-mm2 works. I could bisect through -rc4-mm1 if it's deemed useful, Andrew just pushed -mm2 before I had a chance. pgpZOCdPoltPA.pgp Description: PGP signature
Re: 2.6.22-rc4-mm1
On Thu, Jun 07, 2007 at 07:02:23PM +0200, Jiri Slaby wrote: > It'Greg KH napsal(a): > > On Thu, Jun 07, 2007 at 05:54:13PM +0200, Jiri Slaby wrote: > >> Tejun Heo napsal(a): > >>> Jiri Slaby wrote: > Tejun Heo napsal(a): > > Jiri Slaby wrote: > >> Yes. Now I'm compiling -rc4-mm2. > > It's probably caused by new sysfs slimdown patches and I'm pretty sure > > -rc4-mm2 would fail the same way. The offending one should be one of > > the following patches. > There's reverted gregkh-driver-block-device in -mm2. So I wanted to give > it a > try. Do you think it's pointless and that patch has no impact on the > behaviour? > >>> I'm not familiar with how lvm vgscan works and the patch does look like > >>> it can affect that. Please give a shot at -mm2. > >> Yup, it works without any further patches. So it seems like > >> gregkh-driver-block-device is the culprit? > > > > Culprit for what kind of symptom? Is CONFIG_SYSFS_DEPRECATED enabled? > > If not, can you try that? > > LVM (lvm whatever) writes can't initialize lock 1 and quits. > > SYSFS_DEPRECATED solves the issue (-rc4-mm2 minus the revert + > SYSFS_DEPRECATED). Great, thanks for letting us know. Kay, what userspace tool is involved here that is getting confused? 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: 2.6.22-rc4-mm1
On Thu, Jun 07, 2007 at 02:48:05PM -0400, Bill Nottingham wrote: > Greg KH ([EMAIL PROTECTED]) said: > > There are a number of distros out there right now who can support that > > option disabled. I'm pretty sure they are the following right now: > > Gentoo unstable (actually stable works now for me, but I'm not > > going to guarantee it just yet...) > > Debian unstable (again stable might work, but I have not heard > > any reports from testers.) > > openSUSE FACTORY (the 10.3 alpha releases) > > > > and now it sounds like Red Hat rawhide will also work properly. > > I suspect while it will work for mkinitrd, the installer will not > work properly. Ah, but the installer doesn't matter until you do a Fedora 8 release, right? This is just for people who want to run their own kernel on an already-set-up Fedora machine. 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: 2.6.22-rc4-mm1
On Thu, Jun 07, 2007 at 08:54:50AM +0200, Jan Engelhardt wrote: > > On Jun 6 2007 16:42, Andrew Morton wrote: > > >> If so then you sent to it me :) > > > >You merged it ;) > > > >> Should I drop it? > > > >Sure, Jan will fix it up, I assume. I might have broken it while repairing > >the reject storm which occurred when that durned HAS_IOMEM thing went in > >all over the tree. > > /me points at Herbert > Andrew would not add options between the "menuconfig CRYPTO" and > the "if CRYPTO" line... :) > > > Jan > > > === > > Unbreak the crypto menu breakage. > > Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]> > > --- > crypto/Kconfig |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > Index: linux-2.6.22-rc4/crypto/Kconfig > === > --- linux-2.6.22-rc4.orig/crypto/Kconfig > +++ linux-2.6.22-rc4/crypto/Kconfig > @@ -7,6 +7,8 @@ menuconfig CRYPTO > help > This option provides the core Cryptographic API. > > +if CRYPTO > + > # > # Generic algorithms support > # > @@ -18,8 +20,6 @@ config XOR_BLOCKS > # > source "crypto/async_tx/Kconfig" > > -if CRYPTO > - > config CRYPTO_ALGAPI > tristate > help This seems to be buggy since the options in crypto/async_tx/Kconfig do not depend on the crypto subsystem (and they are not user visible options that get select'ed). 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 - 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: 2.6.22-rc4-mm1
Greg KH ([EMAIL PROTECTED]) said: > There are a number of distros out there right now who can support that > option disabled. I'm pretty sure they are the following right now: > Gentoo unstable (actually stable works now for me, but I'm not >going to guarantee it just yet...) > Debian unstable (again stable might work, but I have not heard >any reports from testers.) > openSUSE FACTORY (the 10.3 alpha releases) > > and now it sounds like Red Hat rawhide will also work properly. I suspect while it will work for mkinitrd, the installer will not work properly. Bill - 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: 2.6.22-rc4-mm1
It'Greg KH napsal(a): > On Thu, Jun 07, 2007 at 05:54:13PM +0200, Jiri Slaby wrote: >> Tejun Heo napsal(a): >>> Jiri Slaby wrote: Tejun Heo napsal(a): > Jiri Slaby wrote: >> Yes. Now I'm compiling -rc4-mm2. > It's probably caused by new sysfs slimdown patches and I'm pretty sure > -rc4-mm2 would fail the same way. The offending one should be one of > the following patches. There's reverted gregkh-driver-block-device in -mm2. So I wanted to give it a try. Do you think it's pointless and that patch has no impact on the behaviour? >>> I'm not familiar with how lvm vgscan works and the patch does look like >>> it can affect that. Please give a shot at -mm2. >> Yup, it works without any further patches. So it seems like >> gregkh-driver-block-device is the culprit? > > Culprit for what kind of symptom? Is CONFIG_SYSFS_DEPRECATED enabled? > If not, can you try that? LVM (lvm whatever) writes can't initialize lock 1 and quits. SYSFS_DEPRECATED solves the issue (-rc4-mm2 minus the revert + SYSFS_DEPRECATED). thanks, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - 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: 2.6.22-rc4-mm1
On Fri, Jun 08, 2007 at 12:39:30AM +0800, WANG Cong wrote: > >Ketchup doesn't even look inside patches, and patch doesn't invent > >names, so something in the bzip2 -> patch(1) -> filesystem chain got > >corrupted. Probably not bzip2, as it has CRCs. > > > > Do you mean ketchup doesn't do anything if a file is corrupted? Ketchup never even sees the filenames. It just calls bzip2 | patch. So it can't be responsible for damaging the filename. > >Do you have ECC memory? > > No. Do you mean it's an error of my RAM? I have never met such things before, > how often does such kind of things happen? May be less often than a bug in > a stable kernel? The best studies I've seen suggest so-called "soft errors" in DRAM happen at a rate of once a week to once a day per gigabyte of RAM at sea-level. It's unknown how many of these errors manifest by visibly corrupting data, but it wouldn't be surprising if it were significantly less than 10%. But ECC is definitely not just for the paranoid! So if I were to rank the reliability of everything, it'd look something like this, highest to lowest: bzip: simple, stable and heavily-used codebase, built-in safeguards like CRC patch: simple, stable, heavily-used, limited detection of input errors CPU: heavily used, very low non-catastrophic failure rate disk: heavily used, CRC on cable, ECC on disk kernel: complex, rapidly-changing, but heavily-used Non-ECC DRAM: significant known transient failure rate When the error rate for the kernel approaches that of DRAM, it gets very hard to assign blame. (And of course, there's the user, who tends to be near the bottom of this range, but I'll let you judge that.) -- Mathematics is the supreme nostalgia of our time. - 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: 2.6.22-rc4-mm1
On Thu, Jun 07, 2007 at 10:59:14AM -0500, Matt Mackall wrote: >On Thu, Jun 07, 2007 at 11:40:08PM +0800, WANG Cong wrote: >> On Thu, Jun 07, 2007 at 09:04:44AM -0500, Matt Mackall wrote: >> >On Thu, Jun 07, 2007 at 02:51:58PM +0800, WANG Cong wrote: >> >> >> Maybe there's something wrong with ketchup. ;( >> >> > >> >> >Can you do an 'lsdiff | grep lguest' on the patch in your ~/.ketchup >> >> >directory? >> >> > >> >> >Ketchup simply applies patches, it never touches filenames directly. >> >> >So for something to go wrong here and drop a file in the tree with a >> >> >damaged pathname, you've either got a damaged patch, a bug in patch >> >> >itself, or some form of filesystem corruption. >> >> >> >> Thanks for your point. >> >> >> >> It should be Documentation/lguest/lguest.c, maybe it was corrupted and >> >> ketchup >> >> backuped it as mlguest.c. >> > >> >It'd be interesting to figure out how that happened, still. >> > >> >If your patch file is intact (are you using GPG's signature-checking >> >support?), the most likely explanation is an operating system or >> >filesystem bug. >> >> Yes, I am using GPG's checking. > >Well that gives a pretty solid assurance that the patch you downloaded >matches the one on kernel.org. And that one doesn't contain an >mlguest.c. > I agree. >Ketchup doesn't even look inside patches, and patch doesn't invent >names, so something in the bzip2 -> patch(1) -> filesystem chain got >corrupted. Probably not bzip2, as it has CRCs. > Do you mean ketchup doesn't do anything if a file is corrupted? >Do you have ECC memory? > No. Do you mean it's an error of my RAM? I have never met such things before, how often does such kind of things happen? May be less often than a bug in a stable kernel? Thanks! - 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: 2.6.22-rc4-mm1
On Thu, Jun 07, 2007 at 09:06:32AM -0700, Andrew Morton wrote: > On Thu, 7 Jun 2007 08:59:53 -0700 Greg KH <[EMAIL PROTECTED]> wrote: > > > On Thu, Jun 07, 2007 at 08:52:00AM -0700, Andrew Morton wrote: > > > On Thu, 7 Jun 2007 08:43:42 -0700 Greg KH <[EMAIL PROTECTED]> wrote: > > > > > > > > Fixed in mkinitrd-6.0.9-6 , which I'll build now and push to > > > > > updates-testing. Thanks for getting my attention here. > > > > > > > > Great, Andrew, can you please reenable the block-device patch that is in > > > > my tree now that the problem has been solved? > > > > > > I think we're screwed, aren't we? Everyone needs to upgrade mkinitrd to > > > be > > > able to boot the kernel? Not viable :( > > > > > > For example, what about my two-year-old yellowdog machine? > > > > Enable CONFIG_SYSFS_DEPRECATED and it should all work just fine. That's > > what Michal said worked for him. > > > > Actually, it _was_ enabled. > > Ho hum, I'll have a poke at it this evening. Yeah, that sounds odd, it should have worked. > So... what's the story here? Should our position be that > CONFIG_SYSFS_DEPRECATED=n should only be used by distro kernel-builders, > who are concurrently shipping userspace which can handle it? Yes. There are a number of distros out there right now who can support that option disabled. I'm pretty sure they are the following right now: Gentoo unstable (actually stable works now for me, but I'm not going to guarantee it just yet...) Debian unstable (again stable might work, but I have not heard any reports from testers.) openSUSE FACTORY (the 10.3 alpha releases) and now it sounds like Red Hat rawhide will also work properly. > And that these distros should (probably) set CONFIG_SYSFS_DEPRECATED=y > in their update kernels for older distributions? Yes, unless they have tested things and it all works properly (all old usages of libsysfs need to be removed and 'odd' initrd scripts need to be updated as in the case of Red Hat.) 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: 2.6.22-rc4-mm1
On Thu, 7 Jun 2007 08:59:53 -0700 Greg KH <[EMAIL PROTECTED]> wrote: > On Thu, Jun 07, 2007 at 08:52:00AM -0700, Andrew Morton wrote: > > On Thu, 7 Jun 2007 08:43:42 -0700 Greg KH <[EMAIL PROTECTED]> wrote: > > > > > > Fixed in mkinitrd-6.0.9-6 , which I'll build now and push to > > > > updates-testing. Thanks for getting my attention here. > > > > > > Great, Andrew, can you please reenable the block-device patch that is in > > > my tree now that the problem has been solved? > > > > I think we're screwed, aren't we? Everyone needs to upgrade mkinitrd to be > > able to boot the kernel? Not viable :( > > > > For example, what about my two-year-old yellowdog machine? > > Enable CONFIG_SYSFS_DEPRECATED and it should all work just fine. That's > what Michal said worked for him. > Actually, it _was_ enabled. Ho hum, I'll have a poke at it this evening. So... what's the story here? Should our position be that CONFIG_SYSFS_DEPRECATED=n should only be used by distro kernel-builders, who are concurrently shipping userspace which can handle it? And that these distros should (probably) set CONFIG_SYSFS_DEPRECATED=y in their update kernels for older distributions? - 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: 2.6.22-rc4-mm1
On Thu, Jun 07, 2007 at 05:54:13PM +0200, Jiri Slaby wrote: > Tejun Heo napsal(a): > > Jiri Slaby wrote: > >> Tejun Heo napsal(a): > >>> Jiri Slaby wrote: > Yes. Now I'm compiling -rc4-mm2. > >>> It's probably caused by new sysfs slimdown patches and I'm pretty sure > >>> -rc4-mm2 would fail the same way. The offending one should be one of > >>> the following patches. > >> There's reverted gregkh-driver-block-device in -mm2. So I wanted to give > >> it a > >> try. Do you think it's pointless and that patch has no impact on the > >> behaviour? > > > > I'm not familiar with how lvm vgscan works and the patch does look like > > it can affect that. Please give a shot at -mm2. > > Yup, it works without any further patches. So it seems like > gregkh-driver-block-device is the culprit? Culprit for what kind of symptom? Is CONFIG_SYSFS_DEPRECATED enabled? If not, can you try that? 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: 2.6.22-rc4-mm1
On Thu, Jun 07, 2007 at 08:52:00AM -0700, Andrew Morton wrote: > On Thu, 7 Jun 2007 08:43:42 -0700 Greg KH <[EMAIL PROTECTED]> wrote: > > > > Fixed in mkinitrd-6.0.9-6 , which I'll build now and push to > > > updates-testing. Thanks for getting my attention here. > > > > Great, Andrew, can you please reenable the block-device patch that is in > > my tree now that the problem has been solved? > > I think we're screwed, aren't we? Everyone needs to upgrade mkinitrd to be > able to boot the kernel? Not viable :( > > For example, what about my two-year-old yellowdog machine? Enable CONFIG_SYSFS_DEPRECATED and it should all work just fine. That's what Michal said worked for him. 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: 2.6.22-rc4-mm1
On Thu, Jun 07, 2007 at 11:40:08PM +0800, WANG Cong wrote: > On Thu, Jun 07, 2007 at 09:04:44AM -0500, Matt Mackall wrote: > >On Thu, Jun 07, 2007 at 02:51:58PM +0800, WANG Cong wrote: > >> >> Maybe there's something wrong with ketchup. ;( > >> > > >> >Can you do an 'lsdiff | grep lguest' on the patch in your ~/.ketchup > >> >directory? > >> > > >> >Ketchup simply applies patches, it never touches filenames directly. > >> >So for something to go wrong here and drop a file in the tree with a > >> >damaged pathname, you've either got a damaged patch, a bug in patch > >> >itself, or some form of filesystem corruption. > >> > >> Thanks for your point. > >> > >> It should be Documentation/lguest/lguest.c, maybe it was corrupted and > >> ketchup > >> backuped it as mlguest.c. > > > >It'd be interesting to figure out how that happened, still. > > > >If your patch file is intact (are you using GPG's signature-checking > >support?), the most likely explanation is an operating system or > >filesystem bug. > > Yes, I am using GPG's checking. Well that gives a pretty solid assurance that the patch you downloaded matches the one on kernel.org. And that one doesn't contain an mlguest.c. Ketchup doesn't even look inside patches, and patch doesn't invent names, so something in the bzip2 -> patch(1) -> filesystem chain got corrupted. Probably not bzip2, as it has CRCs. Do you have ECC memory? -- Mathematics is the supreme nostalgia of our time. - 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: 2.6.22-rc4-mm1
On Thu, Jun 07, 2007 at 11:25:57AM -0400, Peter Jones wrote: > Kay Sievers wrote: > > On Thu, 2007-06-07 at 11:41 +0200, Michal Piotrowski wrote: > >> Kay Sievers pisze: > >>> On Thu, 2007-06-07 at 10:40 +0200, Michal Piotrowski wrote: > Kay Sievers pisze: > > On Wed, 2007-06-06 at 20:48 +0200, Michal Piotrowski wrote: > >> Andrew Morton pisze: > >>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/ > >>> > >> Kay, your patch gregkh-driver-block-device.patch breaks Fedora 7 > >> initrd > >> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.22-rc4-mm1/initrd.jpg > >> > >> Please fix it ASAP, I can't test kernel... > > Do you have CONFIG_SYSFS_DEPRECATED set or unset? > > > > Kay > > > > > cat ../linux-mm-bo/.config | grep CONFIG_SYSFS_DEPRECATED > # CONFIG_SYSFS_DEPRECATED is not set > >>> Oh, could you possibly try (with the block patch included) setting it to > >>> yes and see if it works? That would help to find what's going wrong. > >> I enabled CONFIG_SYSFS_DEPRECATED and 2.6.22-rc4-mm2 boots fine. > > Michal, thanks a lot for the testing. > > Peter, looking at your mkinitrd code, it works only with > > CONFIG_SYSFS_DEPRECATED enabled when block devices are converted to > > class devices. > > Any chance to replace lstat() with stat() while looking for devices in > > sysfs? Remember, _anything_ in sysfs can be symlink or a directory, you > > can't assume one or the other. When things change internally in the > > kernel, we can often provide symlinks for backwards compatibility, but > > lstat() obviously can't works here. > > Fixed in mkinitrd-6.0.9-6 , which I'll build now and push to > updates-testing. Thanks for getting my attention here. Great, Andrew, can you please reenable the block-device patch that is in my tree now that the problem has been solved? 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: 2.6.22-rc4-mm1
Tejun Heo napsal(a): > Jiri Slaby wrote: >> Tejun Heo napsal(a): >>> Jiri Slaby wrote: Yes. Now I'm compiling -rc4-mm2. >>> It's probably caused by new sysfs slimdown patches and I'm pretty sure >>> -rc4-mm2 would fail the same way. The offending one should be one of >>> the following patches. >> There's reverted gregkh-driver-block-device in -mm2. So I wanted to give it a >> try. Do you think it's pointless and that patch has no impact on the >> behaviour? > > I'm not familiar with how lvm vgscan works and the patch does look like > it can affect that. Please give a shot at -mm2. Yup, it works without any further patches. So it seems like gregkh-driver-block-device is the culprit? regards, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - 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: 2.6.22-rc4-mm1
On Thu, 7 Jun 2007 08:43:42 -0700 Greg KH <[EMAIL PROTECTED]> wrote: > > Fixed in mkinitrd-6.0.9-6 , which I'll build now and push to > > updates-testing. Thanks for getting my attention here. > > Great, Andrew, can you please reenable the block-device patch that is in > my tree now that the problem has been solved? I think we're screwed, aren't we? Everyone needs to upgrade mkinitrd to be able to boot the kernel? Not viable :( For example, what about my two-year-old yellowdog machine? - 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: 2.6.22-rc4-mm1
On Thu, Jun 07, 2007 at 09:04:44AM -0500, Matt Mackall wrote: >On Thu, Jun 07, 2007 at 02:51:58PM +0800, WANG Cong wrote: >> >> Maybe there's something wrong with ketchup. ;( >> > >> >Can you do an 'lsdiff | grep lguest' on the patch in your ~/.ketchup >> >directory? >> > >> >Ketchup simply applies patches, it never touches filenames directly. >> >So for something to go wrong here and drop a file in the tree with a >> >damaged pathname, you've either got a damaged patch, a bug in patch >> >itself, or some form of filesystem corruption. >> >> Thanks for your point. >> >> It should be Documentation/lguest/lguest.c, maybe it was corrupted and >> ketchup >> backuped it as mlguest.c. > >It'd be interesting to figure out how that happened, still. > >If your patch file is intact (are you using GPG's signature-checking >support?), the most likely explanation is an operating system or >filesystem bug. Yes, I am using GPG's checking. I think the most possible reason is that source file might be corrupted. It's hardly the filesystem's fault, since I am using a stable kernel. > >Can you reproduce it? May be very hard.;( I deleted all the files of that version and download a new version to use. Thanks! - 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: 2.6.22-rc4-mm1
On Thu, 7 Jun 2007 21:47:06 +0900 KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
> Question.
>
> While writing memory unplug, I noticed this code.
> ==
> static int
> fixup_anon_page(pte_t *pte, unsigned long start, unsigned long end, void
> *priv)
> {
> struct vm_area_struct *vma = priv;
> struct page *page = vm_normal_page(vma, start, *pte);
>
> if (page && PageAnon(page))
> page->index = linear_page_index(vma, start);
>
> return 0;
> }
>
> static int fixup_anon_pages(struct vm_area_struct *vma)
> {
> struct mm_walk walk = {
> .pte_entry = fixup_anon_page,
> };
>
> return walk_page_range(vma->vm_mm,
> vma->vm_start, vma->vm_end, , vma);
> }
I assume the above is your code - it's not in the tree?
>
> I think that 'pte' passed to fixup_anon_page() by walk_page_range()
> is not guaranteed to be 'Present'.
yup - the pagewalker only checks for !pte_none().
> Then, vm_normal_page() will show print_bad_pte().
> If this never occur now, I'll add my own check code for memory migration by
> kernel here.
Yes, you'll need to perform additional filtering where appropriate.
> (Sorry, I can't find who should be CCed.)
Matt and David did most of the work here.
-
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: 2.6.22-rc4-mm1
Kay Sievers wrote: On Thu, 2007-06-07 at 11:41 +0200, Michal Piotrowski wrote: Kay Sievers pisze: On Thu, 2007-06-07 at 10:40 +0200, Michal Piotrowski wrote: Kay Sievers pisze: On Wed, 2007-06-06 at 20:48 +0200, Michal Piotrowski wrote: Andrew Morton pisze: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/ Kay, your patch gregkh-driver-block-device.patch breaks Fedora 7 initrd http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.22-rc4-mm1/initrd.jpg Please fix it ASAP, I can't test kernel... Do you have CONFIG_SYSFS_DEPRECATED set or unset? Kay cat ../linux-mm-bo/.config | grep CONFIG_SYSFS_DEPRECATED # CONFIG_SYSFS_DEPRECATED is not set Oh, could you possibly try (with the block patch included) setting it to yes and see if it works? That would help to find what's going wrong. I enabled CONFIG_SYSFS_DEPRECATED and 2.6.22-rc4-mm2 boots fine. Michal, thanks a lot for the testing. Peter, looking at your mkinitrd code, it works only with CONFIG_SYSFS_DEPRECATED enabled when block devices are converted to class devices. Any chance to replace lstat() with stat() while looking for devices in sysfs? Remember, _anything_ in sysfs can be symlink or a directory, you can't assume one or the other. When things change internally in the kernel, we can often provide symlinks for backwards compatibility, but lstat() obviously can't works here. Fixed in mkinitrd-6.0.9-6 , which I'll build now and push to updates-testing. Thanks for getting my attention here. -- Peter - 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: 2.6.22-rc4-mm1
On Thu, 2007-06-07 at 11:41 +0200, Michal Piotrowski wrote: > Kay Sievers pisze: > > On Thu, 2007-06-07 at 10:40 +0200, Michal Piotrowski wrote: > >> Kay Sievers pisze: > >>> On Wed, 2007-06-06 at 20:48 +0200, Michal Piotrowski wrote: > Andrew Morton pisze: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/ > > > Kay, your patch gregkh-driver-block-device.patch breaks Fedora 7 initrd > http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.22-rc4-mm1/initrd.jpg > > Please fix it ASAP, I can't test kernel... > >>> Do you have CONFIG_SYSFS_DEPRECATED set or unset? > >>> > >>> Kay > >>> > >>> > >> cat ../linux-mm-bo/.config | grep CONFIG_SYSFS_DEPRECATED > >> # CONFIG_SYSFS_DEPRECATED is not set > > > > Oh, could you possibly try (with the block patch included) setting it to > > yes and see if it works? That would help to find what's going wrong. > > I enabled CONFIG_SYSFS_DEPRECATED and 2.6.22-rc4-mm2 boots fine. Michal, thanks a lot for the testing. Peter, looking at your mkinitrd code, it works only with CONFIG_SYSFS_DEPRECATED enabled when block devices are converted to class devices. Any chance to replace lstat() with stat() while looking for devices in sysfs? Remember, _anything_ in sysfs can be symlink or a directory, you can't assume one or the other. When things change internally in the kernel, we can often provide symlinks for backwards compatibility, but lstat() obviously can't works here. Thanks, Kay - 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: 2.6.22-rc4-mm1
On Wed, 6 Jun 2007, Andrew Morton wrote: > On Wed, 6 Jun 2007 21:58:38 +0100 Grant Wilson <[EMAIL PROTECTED]> wrote: > > > On Wednesday 06 June 2007 10:07:37 Andrew Morton wrote: > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/ > > > > Patch 'usb-try-to-debug-bug-8561' triggers when I plug in a usb flash drive: > > Cool, thanks. > > > [10998.881000] usb 1-10: new high speed USB device using ehci_hcd and > > address 3 > > [10999.001000] usb 1-10: new device found, idVendor=13fe, idProduct=1a00 > > [10999.002000] usb 1-10: new device strings: Mfr=1, Product=2, > > SerialNumber=3 > > [10999.016000] usb 1-10: Product: USB DISK 2.0 > > [10999.025000] usb 1-10: Manufacturer: > > [10999.033000] usb 1-10: SerialNumber: 07720947018D > > [10999.034000] usb 1-10: configuration #1 chosen from 1 choice > > [10999.047000] scsi8 : SCSI emulation for USB Mass Storage devices > > [11004.055000] WARNING: at drivers/usb/core/urb.c:293 usb_submit_urb() > > [11004.055000] > > [11004.055000] Call Trace: > > [11004.055000] [] dump_trace+0x43f/0x480 > > [11004.055000] [] show_trace+0x43/0x70 > > [11004.055000] [] dump_stack+0x15/0x20 > > [11004.055000] [] usb_submit_urb+0x224/0x240 > > [11004.055000] [] usb_sg_wait+0xd5/0x180 > > [11004.055000] [] usb_stor_bulk_transfer_sg+0xc4/0x120 > > [11004.055000] [] usb_stor_Bulk_transport+0x151/0x2e0 > > [11004.055000] [] usb_stor_invoke_transport+0x37/0x380 > > [11004.055000] [] > > usb_stor_transparent_scsi_command+0x9/0x10 > > [11004.055000] [] usb_stor_control_thread+0x18a/0x230 > > [11004.055000] [] kthread+0x4d/0x80 > > [11004.055000] [] child_rip+0xa/0x12 > > > > Alan, you got a bite - reel her in! Thanks for forwarding the message. Unforunately it's a false alarm. As mentioned in the original patch, the test it uses isn't precise. To tell you the truth, I rather think there's not much point in keeping usb-try-to-debug-bug-8561.patch around. Anything seriously wrong that it could catch ought to have shown up long ago. And it is now clear that bug 8561 has nothing to do with this; it is a programming error common to many of the USB serial drivers. (Still waiting to hear back from Paulo Pereira whether the fix to the USB Option driver works...) My vote goes toward reverting usb-try-to-debug-bug-8561.patch. However just to be thorough, for anyone wants to keep it here's an untested patch to remove those false alarms. Alan Stern - Remove some false alarms generated by usb-try-to-debug-bug-8561.patch. Signed-off-by: Alan Stern <[EMAIL PROTECTED]> --- Index: usb-2.6/drivers/usb/core/message.c === --- usb-2.6.orig/drivers/usb/core/message.c +++ usb-2.6/drivers/usb/core/message.c @@ -404,8 +404,6 @@ int usb_sg_init ( io->urbs [i]->complete = sg_complete; io->urbs [i]->context = io; - io->urbs [i]->status = -EINPROGRESS; - io->urbs [i]->actual_length = 0; /* * Some systems need to revert to PIO when DMA is temporarily - 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: 2.6.22-rc4-mm1
On Thu, Jun 07, 2007 at 02:51:58PM +0800, WANG Cong wrote: > >> Maybe there's something wrong with ketchup. ;( > > > >Can you do an 'lsdiff | grep lguest' on the patch in your ~/.ketchup > >directory? > > > >Ketchup simply applies patches, it never touches filenames directly. > >So for something to go wrong here and drop a file in the tree with a > >damaged pathname, you've either got a damaged patch, a bug in patch > >itself, or some form of filesystem corruption. > > Thanks for your point. > > It should be Documentation/lguest/lguest.c, maybe it was corrupted and ketchup > backuped it as mlguest.c. It'd be interesting to figure out how that happened, still. If your patch file is intact (are you using GPG's signature-checking support?), the most likely explanation is an operating system or filesystem bug. Can you reproduce it? -- Mathematics is the supreme nostalgia of our time. - 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: 2.6.22-rc4-mm1
Question.
While writing memory unplug, I noticed this code.
==
static int
fixup_anon_page(pte_t *pte, unsigned long start, unsigned long end, void *priv)
{
struct vm_area_struct *vma = priv;
struct page *page = vm_normal_page(vma, start, *pte);
if (page && PageAnon(page))
page->index = linear_page_index(vma, start);
return 0;
}
static int fixup_anon_pages(struct vm_area_struct *vma)
{
struct mm_walk walk = {
.pte_entry = fixup_anon_page,
};
return walk_page_range(vma->vm_mm,
vma->vm_start, vma->vm_end, , vma);
}
==
I think that 'pte' passed to fixup_anon_page() by walk_page_range()
is not guaranteed to be 'Present'.
Then, vm_normal_page() will show print_bad_pte().
If this never occur now, I'll add my own check code for memory migration by
kernel here.
(Sorry, I can't find who should be CCed.)
-Kame
-
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: [2.6.22-rc4-mm1] ACPI Exception (processor_throttling)
Luming Yu pisze: > Please test the attached patch. > It works. I still have exceptions in dmesg (probably my dsdt doesn't support _PTC and _TSS), but already I can read /proc/acpi/processor/CPU0/throttling: [EMAIL PROTECTED]:~$ cat /proc/acpi/processor/CPU0/throttling state count: 8 active state:T0 state available: T0 to T7 states: *T0: 00% T1: 12% T2: 25% T3: 37% T4: 50% T5: 62% T6: 75% T7: 87% > Thanks, > Luming > Thanks for help. -- Maciej Rutecki http://www.maciek.unixy.pl smime.p7s Description: S/MIME Cryptographic Signature
Re: 2.6.22-rc4-mm1
Kay Sievers pisze: On Thu, 2007-06-07 at 10:40 +0200, Michal Piotrowski wrote: Kay Sievers pisze: On Wed, 2007-06-06 at 20:48 +0200, Michal Piotrowski wrote: Andrew Morton pisze: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/ Kay, your patch gregkh-driver-block-device.patch breaks Fedora 7 initrd http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.22-rc4-mm1/initrd.jpg Please fix it ASAP, I can't test kernel... Do you have CONFIG_SYSFS_DEPRECATED set or unset? Kay cat ../linux-mm-bo/.config | grep CONFIG_SYSFS_DEPRECATED # CONFIG_SYSFS_DEPRECATED is not set Oh, could you possibly try (with the block patch included) setting it to yes and see if it works? That would help to find what's going wrong. I enabled CONFIG_SYSFS_DEPRECATED and 2.6.22-rc4-mm2 boots fine. Regards, Michal -- "Najbardziej brakowało mi twojego milczenia." -- Andrzej Sapkowski "Coś więcej" - 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: [2.6.22-rc4-mm1] ACPI Exception (processor_throttling)
Maciej Rutecki pisze: > ACPI Exception (processor_throttling-0084): AE_NOT_FOUND, Evaluating > _PTC [20070126] > ACPI Exception (processor_throttling-0147): AE_NOT_FOUND, Evaluating > _TSS [20070126] > > On 2.6.20.9 I don't have this exceptions. > > Other problem: > > 2.6.22rc4-mm1: > rutek:/home/maciek# cat /proc/acpi/processor/CPU0/throttling > Naruszenie ochrony pamięci (segmentation fault) Update (2.6.22-rc4-mm2): rutek:/home/maciek# cat /proc/acpi/processor/CPU0/throttling acpi_processor_throttling_seq_show() is busted rutek:/home/maciek# cat /proc/acpi/processor/CPU1/throttling acpi_processor_throttling_seq_show() is busted -- Maciej Rutecki http://www.maciek.unixy.pl smime.p7s Description: S/MIME Cryptographic Signature
Re: [2.6.22-rc4-mm1] ACPI Exception (processor_throttling)
Please test the attached patch. Thanks, Luming On 6/7/07, Maciej Rutecki <[EMAIL PROTECTED]> wrote: ACPI Exception (processor_throttling-0084): AE_NOT_FOUND, Evaluating _PTC [20070126] ACPI Exception (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126] On 2.6.20.9 I don't have this exceptions. Other problem: 2.6.22rc4-mm1: rutek:/home/maciek# cat /proc/acpi/processor/CPU0/throttling Naruszenie ochrony pamięci (segmentation fault) compared to 2.6.20.9: [EMAIL PROTECTED]:~$ cat /proc/acpi/processor/CPU0/throttling state count: 8 active state:T0 states: *T0: 00% T1: 12% T2: 25% T3: 37% T4: 50% T5: 62% T6: 75% T7: 87% Other info (2.6.22-rc4-mm1): rutek:/home/maciek# ls /proc/acpi/processor/CPU0/ info limit power throttling rutek:/home/maciek# cat /proc/acpi/processor/CPU0/info processor id:0 acpi id: 1 bus mastering control: yes power management:yes throttling control: yes limit interface: yes rutek:/home/maciek# cat /proc/acpi/processor/CPU0/limit active limit:P0:T0 user limit: P0:T0 thermal limit: P0:T0 rutek:/home/maciek# cat /proc/acpi/processor/CPU0/power active state:C0 max_cstate: C8 bus master activity: maximum allowed latency: 8000 usec states: C1: type[C1] promotion[--] demotion[--] latency[001] usage[] duration[] C2: type[C2] promotion[--] demotion[--] latency[001] usage[] duration[] For CPU1 is similar. config, dmesg, acpidump: http://www.unixy.pl/maciek/download/kernel/2.6.22-rc4-mm1/ -- Maciej Rutecki http://www.maciek.unixy.pl t.patch Description: Binary data
Re: 2.6.22-rc4-mm1
On Thu, 2007-06-07 at 10:40 +0200, Michal Piotrowski wrote: > Kay Sievers pisze: > > On Wed, 2007-06-06 at 20:48 +0200, Michal Piotrowski wrote: > >> Andrew Morton pisze: > >>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/ > >>> > >> Kay, your patch gregkh-driver-block-device.patch breaks Fedora 7 initrd > >> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.22-rc4-mm1/initrd.jpg > >> > >> Please fix it ASAP, I can't test kernel... > > > > Do you have CONFIG_SYSFS_DEPRECATED set or unset? > > > > Kay > > > > > > cat ../linux-mm-bo/.config | grep CONFIG_SYSFS_DEPRECATED > # CONFIG_SYSFS_DEPRECATED is not set Oh, could you possibly try (with the block patch included) setting it to yes and see if it works? That would help to find what's going wrong. Thanks, Kay - 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: 2.6.22-rc4-mm1
Kay Sievers pisze: On Wed, 2007-06-06 at 20:48 +0200, Michal Piotrowski wrote: Andrew Morton pisze: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/ Kay, your patch gregkh-driver-block-device.patch breaks Fedora 7 initrd http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.22-rc4-mm1/initrd.jpg Please fix it ASAP, I can't test kernel... Do you have CONFIG_SYSFS_DEPRECATED set or unset? Kay cat ../linux-mm-bo/.config | grep CONFIG_SYSFS_DEPRECATED # CONFIG_SYSFS_DEPRECATED is not set Regards, Michal -- "Najbardziej brakowało mi twojego milczenia." -- Andrzej Sapkowski "Coś więcej" - 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: 2.6.22-rc4-mm1
Jiri Slaby wrote: > Tejun Heo napsal(a): >> Jiri Slaby wrote: >>> Yes. Now I'm compiling -rc4-mm2. >> It's probably caused by new sysfs slimdown patches and I'm pretty sure >> -rc4-mm2 would fail the same way. The offending one should be one of >> the following patches. > > There's reverted gregkh-driver-block-device in -mm2. So I wanted to give it a > try. Do you think it's pointless and that patch has no impact on the > behaviour? I'm not familiar with how lvm vgscan works and the patch does look like it can affect that. Please give a shot at -mm2. Thanks a lot. -- tejun - 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: 2.6.22-rc4-mm1
Tejun Heo napsal(a): > Jiri Slaby wrote: >> Yes. Now I'm compiling -rc4-mm2. > > It's probably caused by new sysfs slimdown patches and I'm pretty sure > -rc4-mm2 would fail the same way. The offending one should be one of > the following patches. There's reverted gregkh-driver-block-device in -mm2. So I wanted to give it a try. Do you think it's pointless and that patch has no impact on the behaviour? > gregkh-driver-sysfs-fix-parent-refcounting-during-rename-and-move.patch > gregkh-driver-sysfs-reorganize-sysfs_new_indoe-and-sysfs_create.patch > gregkh-driver-sysfs-use-iget_locked-instead-of-new_inode.patch > gregkh-driver-sysfs-fix-root-sysfs_dirent-root-dentry-association.patch > gregkh-driver-sysfs-move-s_active-functions-to-fs-sysfs-dirc.patch > gregkh-driver-sysfs-slim-down-sysfs_dirent-s_active.patch > gregkh-driver-sysfs-use-singly-linked-list-for-sysfs_dirent-tree.patch > > Can you bisect the above patches? Sure, in 12 hours or tomorrow. thanks, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - 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: 2.6.22-rc4-mm1
On Thu, 7 Jun 2007 17:01:08 +1000 Herbert Xu <[EMAIL PROTECTED]> wrote: > On Thu, Jun 07, 2007 at 08:54:50AM +0200, Jan Engelhardt wrote: > > > > /me points at Herbert > > Andrew would not add options between the "menuconfig CRYPTO" and > > the "if CRYPTO" line... :) > > Actually this patch is not even in my tree :) uh, OK, sorry. > > Index: linux-2.6.22-rc4/crypto/Kconfig > > === > > --- linux-2.6.22-rc4.orig/crypto/Kconfig > > +++ linux-2.6.22-rc4/crypto/Kconfig > > @@ -7,6 +7,8 @@ menuconfig CRYPTO > > help > > This option provides the core Cryptographic API. > > > > +if CRYPTO > > + > > # > > # Generic algorithms support > > # > > @@ -18,8 +20,6 @@ config XOR_BLOCKS > > # > > source "crypto/async_tx/Kconfig" > > Andrew, do you want me to pick the async_tx stuff up instead? > I wouldn't recommend it. It's an ongoing source of bustage frankly, has a habit of getting unpleasantly tangled with git-ioat.patch and afaik is still awaiting a go-ahead from Neil. - 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: 2.6.22-rc4-mm1
Jiri Slaby wrote: >>>> Here it is - please test? >>> Ok, this solves this problem, but LVM is broken. Seems similar to >>> Re: 2.6.22-rc4-mm1 - 'lvm vgscan' busticated again... >>> Message-ID: <[EMAIL PROTECTED]> >>> Will try to play with this. >> Did -rc3-mm1 work? Hmmm... I see. > Yes. Now I'm compiling -rc4-mm2. It's probably caused by new sysfs slimdown patches and I'm pretty sure -rc4-mm2 would fail the same way. The offending one should be one of the following patches. gregkh-driver-sysfs-fix-parent-refcounting-during-rename-and-move.patch gregkh-driver-sysfs-reorganize-sysfs_new_indoe-and-sysfs_create.patch gregkh-driver-sysfs-use-iget_locked-instead-of-new_inode.patch gregkh-driver-sysfs-fix-root-sysfs_dirent-root-dentry-association.patch gregkh-driver-sysfs-move-s_active-functions-to-fs-sysfs-dirc.patch gregkh-driver-sysfs-slim-down-sysfs_dirent-s_active.patch gregkh-driver-sysfs-use-singly-linked-list-for-sysfs_dirent-tree.patch Can you bisect the above patches? -- tejun - 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: 2.6.22-rc4-mm1
Tejun Heo napsal(a): > Jiri Slaby wrote: >> Andrew Morton napsal(a): >>> On Wed, 06 Jun 2007 17:34:16 +0200 Jiri Slaby <[EMAIL PROTECTED]> wrote: >>> >>>> Mikael Pettersson napsal(a): >>>>> On Wed, 06 Jun 2007 15:04:00 +0200, Jiri Slaby wrote: >>>>>> Andrew Morton napsal(a): >>>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/ >>>>>> It freezes during bootup while searching for sata drives on >>>>>> sata_promise. There >>>>>> were 2 issues with sata_promise in -rc4 IIRC, one was fixed, the latter >>>>>> remains >>>>>> unresolved. Or, should be this solved too, Mikael, Tejun and is this yet >>>>>> eanother problem? (In this case I'll post dmesg and co.) >>>>> I know of only one sata_promise-specific issue in 2.6.22-rc4. >>>>> Tejun's "sata_promise: use TF interface for polling NODATA commands" >>>>> patch posted today fixes it. >>>> It's in that -mm, so I think, this seems to be another problem. >>> No, it wasn't in 2.6.22-rc4-mm1. >> Huh, what did I smoke? Something rejects to patch and now I don't know what. >> >>> Here it is - please test? >> Ok, this solves this problem, but LVM is broken. Seems similar to >> Re: 2.6.22-rc4-mm1 - 'lvm vgscan' busticated again... >> Message-ID: <[EMAIL PROTECTED]> >> Will try to play with this. > > Did -rc3-mm1 work? Yes. Now I'm compiling -rc4-mm2. regards, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - 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: 2.6.22-rc4-mm1
On Thu, Jun 07, 2007 at 08:54:50AM +0200, Jan Engelhardt wrote:
>
> /me points at Herbert
> Andrew would not add options between the "menuconfig CRYPTO" and
> the "if CRYPTO" line... :)
Actually this patch is not even in my tree :)
> Index: linux-2.6.22-rc4/crypto/Kconfig
> ===
> --- linux-2.6.22-rc4.orig/crypto/Kconfig
> +++ linux-2.6.22-rc4/crypto/Kconfig
> @@ -7,6 +7,8 @@ menuconfig CRYPTO
> help
> This option provides the core Cryptographic API.
>
> +if CRYPTO
> +
> #
> # Generic algorithms support
> #
> @@ -18,8 +20,6 @@ config XOR_BLOCKS
> #
> source "crypto/async_tx/Kconfig"
Andrew, do you want me to pick the async_tx stuff up instead?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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: 2.6.22-rc4-mm1
On Jun 6 2007 16:42, Andrew Morton wrote: >> If so then you sent to it me :) > >You merged it ;) > >> Should I drop it? > >Sure, Jan will fix it up, I assume. I might have broken it while repairing >the reject storm which occurred when that durned HAS_IOMEM thing went in >all over the tree. /me points at Herbert Andrew would not add options between the "menuconfig CRYPTO" and the "if CRYPTO" line... :) Jan === Unbreak the crypto menu breakage. Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]> --- crypto/Kconfig |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: linux-2.6.22-rc4/crypto/Kconfig === --- linux-2.6.22-rc4.orig/crypto/Kconfig +++ linux-2.6.22-rc4/crypto/Kconfig @@ -7,6 +7,8 @@ menuconfig CRYPTO help This option provides the core Cryptographic API. +if CRYPTO + # # Generic algorithms support # @@ -18,8 +20,6 @@ config XOR_BLOCKS # source "crypto/async_tx/Kconfig" -if CRYPTO - config CRYPTO_ALGAPI tristate help - 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: 2.6.22-rc4-mm1
Jiri Slaby wrote: > Andrew Morton napsal(a): >> On Wed, 06 Jun 2007 17:34:16 +0200 Jiri Slaby <[EMAIL PROTECTED]> wrote: >> >>> Mikael Pettersson napsal(a): >>>> On Wed, 06 Jun 2007 15:04:00 +0200, Jiri Slaby wrote: >>>>> Andrew Morton napsal(a): >>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/ >>>>> It freezes during bootup while searching for sata drives on sata_promise. >>>>> There >>>>> were 2 issues with sata_promise in -rc4 IIRC, one was fixed, the latter >>>>> remains >>>>> unresolved. Or, should be this solved too, Mikael, Tejun and is this yet >>>>> eanother problem? (In this case I'll post dmesg and co.) >>>> I know of only one sata_promise-specific issue in 2.6.22-rc4. >>>> Tejun's "sata_promise: use TF interface for polling NODATA commands" >>>> patch posted today fixes it. >>> It's in that -mm, so I think, this seems to be another problem. >> No, it wasn't in 2.6.22-rc4-mm1. > > Huh, what did I smoke? Something rejects to patch and now I don't know what. > >> Here it is - please test? > > Ok, this solves this problem, but LVM is broken. Seems similar to > Re: 2.6.22-rc4-mm1 - 'lvm vgscan' busticated again... > Message-ID: <[EMAIL PROTECTED]> > Will try to play with this. Did -rc3-mm1 work? -- tejun - 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: 2.6.22-rc4-mm1
On Thu, Jun 07, 2007 at 12:59:13AM -0500, Matt Mackall wrote: >On Thu, Jun 07, 2007 at 10:26:09AM +0800, WANG Cong wrote: >> On Wed, Jun 06, 2007 at 11:09:31AM -0700, Andrew Morton wrote: >> >On Thu, 7 Jun 2007 00:19:36 +0800 WANG Cong <[EMAIL PROTECTED]> wrote: >> > >> >> On Wed, Jun 06, 2007 at 02:07:37AM -0700, Andrew Morton wrote: >> >> > >> >> >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/ >> >> > >> >> >- Somebody broke it on my powerpc G5, but I didn't have time to do yet >> >> > another bisection yet. >> >> > >> >> >> >> It seems strange that a new C source file (mlguest.c) appears in the top >> >> dir of the >> >> kernel source. There are some problems with it. >> >> >> >> First, I used `make mlguest.o` to compile that file, but I got tons of >> >> warnings and errors. >> >> (Too many to put here.) What's wrong with it? Or I didn't >> >> compile/configure it correctly? >> >> >> >> Second, mlguest.c #includes a head file named >> >> "../../include/linux/lguest_launcher.h". >> >> Since mlguest.c is in the top dir, so where is >> >> ../../include/linux/lguest_launcher.h? >> >> >> > >> >Confused. I've grepped the entire universe here for "mlguest" and came up >> >with nothing. >> > >> >I don't have a clue where that file came from on your system. >> >> >> I used 'ketchup' to update my kernel from -rc3 to -rc4-mm1. I got the follow: >> >> [EMAIL PROTECTED] linux-2.6.22-rc4-mm1]$ ls >> arch Documentation ipc MakefileREADME >> System.map >> blockdriversKbuild mlguest.c REPORTING-BUGS usr >> COPYING fs kernel mm scripts vmlinux >> CREDITS includelib Module.symvers security >> crypto init MAINTAINERS net sound >> >> Maybe there's something wrong with ketchup. ;( > >Can you do an 'lsdiff | grep lguest' on the patch in your ~/.ketchup directory? > >Ketchup simply applies patches, it never touches filenames directly. >So for something to go wrong here and drop a file in the tree with a >damaged pathname, you've either got a damaged patch, a bug in patch >itself, or some form of filesystem corruption. Thanks for your point. It should be Documentation/lguest/lguest.c, maybe it was corrupted and ketchup backuped it as mlguest.c. Sorry for this. - 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: 2.6.22-rc4-mm1 - 'lvm vgscan' busticated again...
[EMAIL PROTECTED] wrote: > On Wed, 06 Jun 2007 02:07:37 PDT, Andrew Morton said: >> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/ > > This one died a horrid death at boot time - console log indicates it found the > hard drive OK, found the 2 partitions on it. But when the initrd ran a > 'lvm vgscan', it didn't find the LVM2 space on /dev/sda2, so it panic'ed when > it fell off the end of the initrd because the root= wasn't there. > > My first guess for blame: > > gregkh-driver-sysfs-allocate-inode-number-using-ida.patch > > as that's awfully similar to > gregkh-driver-sysfs-fix-i_ino-handling-in-sysfs.patch > that broke 'lvm vgscan' for me in the same way on 21-rc7-mm[12]. > > I'll hopefully get a chance to revert that one and test later today - a quick > 'patch -p1 -R --dry-run' shows a number of conflicts that will need > hand-fixing > at the very least. Did rc3-mm1 work? Can you find out the first broken -mm? Thanks. -- tejun - 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: 2.6.22-rc4-mm1
On Wed, Jun 06, 2007 at 06:09:24PM -0700, Andrew Morton wrote: > ooh, yes, lockdep_init() really does want to be called before anything > else. > So do we take it that this code hasn't been tested with lockdep? Please > don't forget that step - lockdep finds some pretty nasty bugs sometimes. > This? I found this patch when I woke and it got things booting with the full -mm stack. Now to fix the sparc32 build and see if it boots. -- wli - 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: 2.6.22-rc4-mm1
On Thu, Jun 07, 2007 at 10:26:09AM +0800, WANG Cong wrote: > On Wed, Jun 06, 2007 at 11:09:31AM -0700, Andrew Morton wrote: > >On Thu, 7 Jun 2007 00:19:36 +0800 WANG Cong <[EMAIL PROTECTED]> wrote: > > > >> On Wed, Jun 06, 2007 at 02:07:37AM -0700, Andrew Morton wrote: > >> > > >> >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/ > >> > > >> >- Somebody broke it on my powerpc G5, but I didn't have time to do yet > >> > another bisection yet. > >> > > >> > >> It seems strange that a new C source file (mlguest.c) appears in the top > >> dir of the > >> kernel source. There are some problems with it. > >> > >> First, I used `make mlguest.o` to compile that file, but I got tons of > >> warnings and errors. > >> (Too many to put here.) What's wrong with it? Or I didn't > >> compile/configure it correctly? > >> > >> Second, mlguest.c #includes a head file named > >> "../../include/linux/lguest_launcher.h". > >> Since mlguest.c is in the top dir, so where is > >> ../../include/linux/lguest_launcher.h? > >> > > > >Confused. I've grepped the entire universe here for "mlguest" and came up > >with nothing. > > > >I don't have a clue where that file came from on your system. > > > I used 'ketchup' to update my kernel from -rc3 to -rc4-mm1. I got the follow: > > [EMAIL PROTECTED] linux-2.6.22-rc4-mm1]$ ls > arch Documentation ipc MakefileREADME > System.map > blockdriversKbuild mlguest.c REPORTING-BUGS usr > COPYING fs kernel mm scripts vmlinux > CREDITS includelib Module.symvers security > crypto init MAINTAINERS net sound > > Maybe there's something wrong with ketchup. ;( Can you do an 'lsdiff | grep lguest' on the patch in your ~/.ketchup directory? Ketchup simply applies patches, it never touches filenames directly. So for something to go wrong here and drop a file in the tree with a damaged pathname, you've either got a damaged patch, a bug in patch itself, or some form of filesystem corruption. -- Mathematics is the supreme nostalgia of our time. - 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: 2.6.22-rc4-mm1
On Thu, 7 Jun 2007 08:34:58 -0700 Andrew Morton [EMAIL PROTECTED] wrote: I assume the above is your code - it's not in the tree? Ah, that code was disappeared in -mm2. But it informed me that I should consider memory unplug v.s. sys_mremap case... Thanks, anyway. -Kame - 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: 2.6.22-rc4-mm1
On Thu, Jun 07, 2007 at 11:59:16AM -0500, Matt Mackall wrote: On Fri, Jun 08, 2007 at 12:39:30AM +0800, WANG Cong wrote: Ketchup doesn't even look inside patches, and patch doesn't invent names, so something in the bzip2 - patch(1) - filesystem chain got corrupted. Probably not bzip2, as it has CRCs. Do you mean ketchup doesn't do anything if a file is corrupted? Ketchup never even sees the filenames. It just calls bzip2 | patch. So it can't be responsible for damaging the filename. Do you have ECC memory? No. Do you mean it's an error of my RAM? I have never met such things before, how often does such kind of things happen? May be less often than a bug in a stable kernel? The best studies I've seen suggest so-called soft errors in DRAM happen at a rate of once a week to once a day per gigabyte of RAM at sea-level. It's unknown how many of these errors manifest by visibly corrupting data, but it wouldn't be surprising if it were significantly less than 10%. But ECC is definitely not just for the paranoid! So if I were to rank the reliability of everything, it'd look something like this, highest to lowest: bzip: simple, stable and heavily-used codebase, built-in safeguards like CRC patch: simple, stable, heavily-used, limited detection of input errors CPU: heavily used, very low non-catastrophic failure rate disk: heavily used, CRC on cable, ECC on disk kernel: complex, rapidly-changing, but heavily-used Non-ECC DRAM: significant known transient failure rate When the error rate for the kernel approaches that of DRAM, it gets very hard to assign blame. (And of course, there's the user, who tends to be near the bottom of this range, but I'll let you judge that.) Good explanation! Thanks! That the RAM error occurs so often really surprises me. I think it might be RAM's fault, because, at least, it's less reproduceable than a bug in a stable kernel. Regards! - 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: 2.6.22-rc4-mm1
On Thu, Jun 07, 2007 at 10:26:09AM +0800, WANG Cong wrote: On Wed, Jun 06, 2007 at 11:09:31AM -0700, Andrew Morton wrote: On Thu, 7 Jun 2007 00:19:36 +0800 WANG Cong [EMAIL PROTECTED] wrote: On Wed, Jun 06, 2007 at 02:07:37AM -0700, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/ - Somebody broke it on my powerpc G5, but I didn't have time to do yet another bisection yet. It seems strange that a new C source file (mlguest.c) appears in the top dir of the kernel source. There are some problems with it. First, I used `make mlguest.o` to compile that file, but I got tons of warnings and errors. (Too many to put here.) What's wrong with it? Or I didn't compile/configure it correctly? Second, mlguest.c #includes a head file named ../../include/linux/lguest_launcher.h. Since mlguest.c is in the top dir, so where is ../../include/linux/lguest_launcher.h? Confused. I've grepped the entire universe here for mlguest and came up with nothing. I don't have a clue where that file came from on your system. I used 'ketchup' to update my kernel from -rc3 to -rc4-mm1. I got the follow: [EMAIL PROTECTED] linux-2.6.22-rc4-mm1]$ ls arch Documentation ipc MakefileREADME System.map blockdriversKbuild mlguest.c REPORTING-BUGS usr COPYING fs kernel mm scripts vmlinux CREDITS includelib Module.symvers security crypto init MAINTAINERS net sound Maybe there's something wrong with ketchup. ;( Can you do an 'lsdiff | grep lguest' on the patch in your ~/.ketchup directory? Ketchup simply applies patches, it never touches filenames directly. So for something to go wrong here and drop a file in the tree with a damaged pathname, you've either got a damaged patch, a bug in patch itself, or some form of filesystem corruption. -- Mathematics is the supreme nostalgia of our time. - 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: 2.6.22-rc4-mm1
On Wed, Jun 06, 2007 at 06:09:24PM -0700, Andrew Morton wrote: ooh, yes, lockdep_init() really does want to be called before anything else. So do we take it that this code hasn't been tested with lockdep? Please don't forget that step - lockdep finds some pretty nasty bugs sometimes. This? I found this patch when I woke and it got things booting with the full -mm stack. Now to fix the sparc32 build and see if it boots. -- wli - 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: 2.6.22-rc4-mm1 - 'lvm vgscan' busticated again...
[EMAIL PROTECTED] wrote: On Wed, 06 Jun 2007 02:07:37 PDT, Andrew Morton said: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/ This one died a horrid death at boot time - console log indicates it found the hard drive OK, found the 2 partitions on it. But when the initrd ran a 'lvm vgscan', it didn't find the LVM2 space on /dev/sda2, so it panic'ed when it fell off the end of the initrd because the root= wasn't there. My first guess for blame: gregkh-driver-sysfs-allocate-inode-number-using-ida.patch as that's awfully similar to gregkh-driver-sysfs-fix-i_ino-handling-in-sysfs.patch that broke 'lvm vgscan' for me in the same way on 21-rc7-mm[12]. I'll hopefully get a chance to revert that one and test later today - a quick 'patch -p1 -R --dry-run' shows a number of conflicts that will need hand-fixing at the very least. Did rc3-mm1 work? Can you find out the first broken -mm? Thanks. -- tejun - 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: 2.6.22-rc4-mm1
On Thu, Jun 07, 2007 at 12:59:13AM -0500, Matt Mackall wrote: On Thu, Jun 07, 2007 at 10:26:09AM +0800, WANG Cong wrote: On Wed, Jun 06, 2007 at 11:09:31AM -0700, Andrew Morton wrote: On Thu, 7 Jun 2007 00:19:36 +0800 WANG Cong [EMAIL PROTECTED] wrote: On Wed, Jun 06, 2007 at 02:07:37AM -0700, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/ - Somebody broke it on my powerpc G5, but I didn't have time to do yet another bisection yet. It seems strange that a new C source file (mlguest.c) appears in the top dir of the kernel source. There are some problems with it. First, I used `make mlguest.o` to compile that file, but I got tons of warnings and errors. (Too many to put here.) What's wrong with it? Or I didn't compile/configure it correctly? Second, mlguest.c #includes a head file named ../../include/linux/lguest_launcher.h. Since mlguest.c is in the top dir, so where is ../../include/linux/lguest_launcher.h? Confused. I've grepped the entire universe here for mlguest and came up with nothing. I don't have a clue where that file came from on your system. I used 'ketchup' to update my kernel from -rc3 to -rc4-mm1. I got the follow: [EMAIL PROTECTED] linux-2.6.22-rc4-mm1]$ ls arch Documentation ipc MakefileREADME System.map blockdriversKbuild mlguest.c REPORTING-BUGS usr COPYING fs kernel mm scripts vmlinux CREDITS includelib Module.symvers security crypto init MAINTAINERS net sound Maybe there's something wrong with ketchup. ;( Can you do an 'lsdiff | grep lguest' on the patch in your ~/.ketchup directory? Ketchup simply applies patches, it never touches filenames directly. So for something to go wrong here and drop a file in the tree with a damaged pathname, you've either got a damaged patch, a bug in patch itself, or some form of filesystem corruption. Thanks for your point. It should be Documentation/lguest/lguest.c, maybe it was corrupted and ketchup backuped it as mlguest.c. Sorry for this. - 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: 2.6.22-rc4-mm1
Jiri Slaby wrote: Andrew Morton napsal(a): On Wed, 06 Jun 2007 17:34:16 +0200 Jiri Slaby [EMAIL PROTECTED] wrote: Mikael Pettersson napsal(a): On Wed, 06 Jun 2007 15:04:00 +0200, Jiri Slaby wrote: Andrew Morton napsal(a): ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/ It freezes during bootup while searching for sata drives on sata_promise. There were 2 issues with sata_promise in -rc4 IIRC, one was fixed, the latter remains unresolved. Or, should be this solved too, Mikael, Tejun and is this yet eanother problem? (In this case I'll post dmesg and co.) I know of only one sata_promise-specific issue in 2.6.22-rc4. Tejun's sata_promise: use TF interface for polling NODATA commands patch posted today fixes it. It's in that -mm, so I think, this seems to be another problem. No, it wasn't in 2.6.22-rc4-mm1. Huh, what did I smoke? Something rejects to patch and now I don't know what. Here it is - please test? Ok, this solves this problem, but LVM is broken. Seems similar to Re: 2.6.22-rc4-mm1 - 'lvm vgscan' busticated again... Message-ID: [EMAIL PROTECTED] Will try to play with this. Did -rc3-mm1 work? -- tejun - 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: 2.6.22-rc4-mm1
On Jun 6 2007 16:42, Andrew Morton wrote: If so then you sent to it me :) You merged it ;) Should I drop it? Sure, Jan will fix it up, I assume. I might have broken it while repairing the reject storm which occurred when that durned HAS_IOMEM thing went in all over the tree. /me points at Herbert Andrew would not add options between the menuconfig CRYPTO and the if CRYPTO line... :) Jan === Unbreak the crypto menu breakage. Signed-off-by: Jan Engelhardt [EMAIL PROTECTED] --- crypto/Kconfig |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: linux-2.6.22-rc4/crypto/Kconfig === --- linux-2.6.22-rc4.orig/crypto/Kconfig +++ linux-2.6.22-rc4/crypto/Kconfig @@ -7,6 +7,8 @@ menuconfig CRYPTO help This option provides the core Cryptographic API. +if CRYPTO + # # Generic algorithms support # @@ -18,8 +20,6 @@ config XOR_BLOCKS # source crypto/async_tx/Kconfig -if CRYPTO - config CRYPTO_ALGAPI tristate help - 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: 2.6.22-rc4-mm1
Tejun Heo napsal(a): Jiri Slaby wrote: Andrew Morton napsal(a): On Wed, 06 Jun 2007 17:34:16 +0200 Jiri Slaby [EMAIL PROTECTED] wrote: Mikael Pettersson napsal(a): On Wed, 06 Jun 2007 15:04:00 +0200, Jiri Slaby wrote: Andrew Morton napsal(a): ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/ It freezes during bootup while searching for sata drives on sata_promise. There were 2 issues with sata_promise in -rc4 IIRC, one was fixed, the latter remains unresolved. Or, should be this solved too, Mikael, Tejun and is this yet eanother problem? (In this case I'll post dmesg and co.) I know of only one sata_promise-specific issue in 2.6.22-rc4. Tejun's sata_promise: use TF interface for polling NODATA commands patch posted today fixes it. It's in that -mm, so I think, this seems to be another problem. No, it wasn't in 2.6.22-rc4-mm1. Huh, what did I smoke? Something rejects to patch and now I don't know what. Here it is - please test? Ok, this solves this problem, but LVM is broken. Seems similar to Re: 2.6.22-rc4-mm1 - 'lvm vgscan' busticated again... Message-ID: [EMAIL PROTECTED] Will try to play with this. Did -rc3-mm1 work? Yes. Now I'm compiling -rc4-mm2. regards, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - 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: 2.6.22-rc4-mm1
On Thu, Jun 07, 2007 at 08:54:50AM +0200, Jan Engelhardt wrote:
/me points at Herbert
Andrew would not add options between the menuconfig CRYPTO and
the if CRYPTO line... :)
Actually this patch is not even in my tree :)
Index: linux-2.6.22-rc4/crypto/Kconfig
===
--- linux-2.6.22-rc4.orig/crypto/Kconfig
+++ linux-2.6.22-rc4/crypto/Kconfig
@@ -7,6 +7,8 @@ menuconfig CRYPTO
help
This option provides the core Cryptographic API.
+if CRYPTO
+
#
# Generic algorithms support
#
@@ -18,8 +20,6 @@ config XOR_BLOCKS
#
source crypto/async_tx/Kconfig
Andrew, do you want me to pick the async_tx stuff up instead?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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: 2.6.22-rc4-mm1
Jiri Slaby wrote: Here it is - please test? Ok, this solves this problem, but LVM is broken. Seems similar to Re: 2.6.22-rc4-mm1 - 'lvm vgscan' busticated again... Message-ID: [EMAIL PROTECTED] Will try to play with this. Did -rc3-mm1 work? Hmmm... I see. Yes. Now I'm compiling -rc4-mm2. It's probably caused by new sysfs slimdown patches and I'm pretty sure -rc4-mm2 would fail the same way. The offending one should be one of the following patches. gregkh-driver-sysfs-fix-parent-refcounting-during-rename-and-move.patch gregkh-driver-sysfs-reorganize-sysfs_new_indoe-and-sysfs_create.patch gregkh-driver-sysfs-use-iget_locked-instead-of-new_inode.patch gregkh-driver-sysfs-fix-root-sysfs_dirent-root-dentry-association.patch gregkh-driver-sysfs-move-s_active-functions-to-fs-sysfs-dirc.patch gregkh-driver-sysfs-slim-down-sysfs_dirent-s_active.patch gregkh-driver-sysfs-use-singly-linked-list-for-sysfs_dirent-tree.patch Can you bisect the above patches? -- tejun - 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: 2.6.22-rc4-mm1
On Thu, 7 Jun 2007 17:01:08 +1000 Herbert Xu [EMAIL PROTECTED] wrote: On Thu, Jun 07, 2007 at 08:54:50AM +0200, Jan Engelhardt wrote: /me points at Herbert Andrew would not add options between the menuconfig CRYPTO and the if CRYPTO line... :) Actually this patch is not even in my tree :) uh, OK, sorry. Index: linux-2.6.22-rc4/crypto/Kconfig === --- linux-2.6.22-rc4.orig/crypto/Kconfig +++ linux-2.6.22-rc4/crypto/Kconfig @@ -7,6 +7,8 @@ menuconfig CRYPTO help This option provides the core Cryptographic API. +if CRYPTO + # # Generic algorithms support # @@ -18,8 +20,6 @@ config XOR_BLOCKS # source crypto/async_tx/Kconfig Andrew, do you want me to pick the async_tx stuff up instead? I wouldn't recommend it. It's an ongoing source of bustage frankly, has a habit of getting unpleasantly tangled with git-ioat.patch and afaik is still awaiting a go-ahead from Neil. - 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: 2.6.22-rc4-mm1
Tejun Heo napsal(a): Jiri Slaby wrote: Yes. Now I'm compiling -rc4-mm2. It's probably caused by new sysfs slimdown patches and I'm pretty sure -rc4-mm2 would fail the same way. The offending one should be one of the following patches. There's reverted gregkh-driver-block-device in -mm2. So I wanted to give it a try. Do you think it's pointless and that patch has no impact on the behaviour? gregkh-driver-sysfs-fix-parent-refcounting-during-rename-and-move.patch gregkh-driver-sysfs-reorganize-sysfs_new_indoe-and-sysfs_create.patch gregkh-driver-sysfs-use-iget_locked-instead-of-new_inode.patch gregkh-driver-sysfs-fix-root-sysfs_dirent-root-dentry-association.patch gregkh-driver-sysfs-move-s_active-functions-to-fs-sysfs-dirc.patch gregkh-driver-sysfs-slim-down-sysfs_dirent-s_active.patch gregkh-driver-sysfs-use-singly-linked-list-for-sysfs_dirent-tree.patch Can you bisect the above patches? Sure, in 12 hours or tomorrow. thanks, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - 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: 2.6.22-rc4-mm1
Jiri Slaby wrote: Tejun Heo napsal(a): Jiri Slaby wrote: Yes. Now I'm compiling -rc4-mm2. It's probably caused by new sysfs slimdown patches and I'm pretty sure -rc4-mm2 would fail the same way. The offending one should be one of the following patches. There's reverted gregkh-driver-block-device in -mm2. So I wanted to give it a try. Do you think it's pointless and that patch has no impact on the behaviour? I'm not familiar with how lvm vgscan works and the patch does look like it can affect that. Please give a shot at -mm2. Thanks a lot. -- tejun - 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: 2.6.22-rc4-mm1
Kay Sievers pisze: On Wed, 2007-06-06 at 20:48 +0200, Michal Piotrowski wrote: Andrew Morton pisze: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/ Kay, your patch gregkh-driver-block-device.patch breaks Fedora 7 initrd http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.22-rc4-mm1/initrd.jpg Please fix it ASAP, I can't test kernel... Do you have CONFIG_SYSFS_DEPRECATED set or unset? Kay cat ../linux-mm-bo/.config | grep CONFIG_SYSFS_DEPRECATED # CONFIG_SYSFS_DEPRECATED is not set Regards, Michal -- Najbardziej brakowało mi twojego milczenia. -- Andrzej Sapkowski Coś więcej - 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: 2.6.22-rc4-mm1
On Thu, 2007-06-07 at 10:40 +0200, Michal Piotrowski wrote: Kay Sievers pisze: On Wed, 2007-06-06 at 20:48 +0200, Michal Piotrowski wrote: Andrew Morton pisze: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/ Kay, your patch gregkh-driver-block-device.patch breaks Fedora 7 initrd http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.22-rc4-mm1/initrd.jpg Please fix it ASAP, I can't test kernel... Do you have CONFIG_SYSFS_DEPRECATED set or unset? Kay cat ../linux-mm-bo/.config | grep CONFIG_SYSFS_DEPRECATED # CONFIG_SYSFS_DEPRECATED is not set Oh, could you possibly try (with the block patch included) setting it to yes and see if it works? That would help to find what's going wrong. Thanks, Kay - 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: [2.6.22-rc4-mm1] ACPI Exception (processor_throttling)
Please test the attached patch. Thanks, Luming On 6/7/07, Maciej Rutecki [EMAIL PROTECTED] wrote: ACPI Exception (processor_throttling-0084): AE_NOT_FOUND, Evaluating _PTC [20070126] ACPI Exception (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126] On 2.6.20.9 I don't have this exceptions. Other problem: 2.6.22rc4-mm1: rutek:/home/maciek# cat /proc/acpi/processor/CPU0/throttling Naruszenie ochrony pamięci (segmentation fault) compared to 2.6.20.9: [EMAIL PROTECTED]:~$ cat /proc/acpi/processor/CPU0/throttling state count: 8 active state:T0 states: *T0: 00% T1: 12% T2: 25% T3: 37% T4: 50% T5: 62% T6: 75% T7: 87% Other info (2.6.22-rc4-mm1): rutek:/home/maciek# ls /proc/acpi/processor/CPU0/ info limit power throttling rutek:/home/maciek# cat /proc/acpi/processor/CPU0/info processor id:0 acpi id: 1 bus mastering control: yes power management:yes throttling control: yes limit interface: yes rutek:/home/maciek# cat /proc/acpi/processor/CPU0/limit active limit:P0:T0 user limit: P0:T0 thermal limit: P0:T0 rutek:/home/maciek# cat /proc/acpi/processor/CPU0/power active state:C0 max_cstate: C8 bus master activity: maximum allowed latency: 8000 usec states: C1: type[C1] promotion[--] demotion[--] latency[001] usage[] duration[] C2: type[C2] promotion[--] demotion[--] latency[001] usage[] duration[] For CPU1 is similar. config, dmesg, acpidump: http://www.unixy.pl/maciek/download/kernel/2.6.22-rc4-mm1/ -- Maciej Rutecki http://www.maciek.unixy.pl t.patch Description: Binary data
Re: [2.6.22-rc4-mm1] ACPI Exception (processor_throttling)
Maciej Rutecki pisze: ACPI Exception (processor_throttling-0084): AE_NOT_FOUND, Evaluating _PTC [20070126] ACPI Exception (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126] On 2.6.20.9 I don't have this exceptions. Other problem: 2.6.22rc4-mm1: rutek:/home/maciek# cat /proc/acpi/processor/CPU0/throttling Naruszenie ochrony pamięci (segmentation fault) Update (2.6.22-rc4-mm2): rutek:/home/maciek# cat /proc/acpi/processor/CPU0/throttling acpi_processor_throttling_seq_show() is busted rutek:/home/maciek# cat /proc/acpi/processor/CPU1/throttling acpi_processor_throttling_seq_show() is busted -- Maciej Rutecki http://www.maciek.unixy.pl smime.p7s Description: S/MIME Cryptographic Signature
Re: 2.6.22-rc4-mm1
Kay Sievers pisze: On Thu, 2007-06-07 at 10:40 +0200, Michal Piotrowski wrote: Kay Sievers pisze: On Wed, 2007-06-06 at 20:48 +0200, Michal Piotrowski wrote: Andrew Morton pisze: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/ Kay, your patch gregkh-driver-block-device.patch breaks Fedora 7 initrd http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.22-rc4-mm1/initrd.jpg Please fix it ASAP, I can't test kernel... Do you have CONFIG_SYSFS_DEPRECATED set or unset? Kay cat ../linux-mm-bo/.config | grep CONFIG_SYSFS_DEPRECATED # CONFIG_SYSFS_DEPRECATED is not set Oh, could you possibly try (with the block patch included) setting it to yes and see if it works? That would help to find what's going wrong. I enabled CONFIG_SYSFS_DEPRECATED and 2.6.22-rc4-mm2 boots fine. Regards, Michal -- Najbardziej brakowało mi twojego milczenia. -- Andrzej Sapkowski Coś więcej - 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: [2.6.22-rc4-mm1] ACPI Exception (processor_throttling)
Luming Yu pisze: Please test the attached patch. It works. I still have exceptions in dmesg (probably my dsdt doesn't support _PTC and _TSS), but already I can read /proc/acpi/processor/CPU0/throttling: [EMAIL PROTECTED]:~$ cat /proc/acpi/processor/CPU0/throttling state count: 8 active state:T0 state available: T0 to T7 states: *T0: 00% T1: 12% T2: 25% T3: 37% T4: 50% T5: 62% T6: 75% T7: 87% Thanks, Luming Thanks for help. -- Maciej Rutecki http://www.maciek.unixy.pl smime.p7s Description: S/MIME Cryptographic Signature
Re: 2.6.22-rc4-mm1
Question.
While writing memory unplug, I noticed this code.
==
static int
fixup_anon_page(pte_t *pte, unsigned long start, unsigned long end, void *priv)
{
struct vm_area_struct *vma = priv;
struct page *page = vm_normal_page(vma, start, *pte);
if (page PageAnon(page))
page-index = linear_page_index(vma, start);
return 0;
}
static int fixup_anon_pages(struct vm_area_struct *vma)
{
struct mm_walk walk = {
.pte_entry = fixup_anon_page,
};
return walk_page_range(vma-vm_mm,
vma-vm_start, vma-vm_end, walk, vma);
}
==
I think that 'pte' passed to fixup_anon_page() by walk_page_range()
is not guaranteed to be 'Present'.
Then, vm_normal_page() will show print_bad_pte().
If this never occur now, I'll add my own check code for memory migration by
kernel here.
(Sorry, I can't find who should be CCed.)
-Kame
-
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: 2.6.22-rc4-mm1
On Thu, Jun 07, 2007 at 02:51:58PM +0800, WANG Cong wrote: Maybe there's something wrong with ketchup. ;( Can you do an 'lsdiff | grep lguest' on the patch in your ~/.ketchup directory? Ketchup simply applies patches, it never touches filenames directly. So for something to go wrong here and drop a file in the tree with a damaged pathname, you've either got a damaged patch, a bug in patch itself, or some form of filesystem corruption. Thanks for your point. It should be Documentation/lguest/lguest.c, maybe it was corrupted and ketchup backuped it as mlguest.c. It'd be interesting to figure out how that happened, still. If your patch file is intact (are you using GPG's signature-checking support?), the most likely explanation is an operating system or filesystem bug. Can you reproduce it? -- Mathematics is the supreme nostalgia of our time. - 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: 2.6.22-rc4-mm1
On Wed, 6 Jun 2007, Andrew Morton wrote: On Wed, 6 Jun 2007 21:58:38 +0100 Grant Wilson [EMAIL PROTECTED] wrote: On Wednesday 06 June 2007 10:07:37 Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/ Patch 'usb-try-to-debug-bug-8561' triggers when I plug in a usb flash drive: Cool, thanks. [10998.881000] usb 1-10: new high speed USB device using ehci_hcd and address 3 [10999.001000] usb 1-10: new device found, idVendor=13fe, idProduct=1a00 [10999.002000] usb 1-10: new device strings: Mfr=1, Product=2, SerialNumber=3 [10999.016000] usb 1-10: Product: USB DISK 2.0 [10999.025000] usb 1-10: Manufacturer: [10999.033000] usb 1-10: SerialNumber: 07720947018D [10999.034000] usb 1-10: configuration #1 chosen from 1 choice [10999.047000] scsi8 : SCSI emulation for USB Mass Storage devices [11004.055000] WARNING: at drivers/usb/core/urb.c:293 usb_submit_urb() [11004.055000] [11004.055000] Call Trace: [11004.055000] [8020d30f] dump_trace+0x43f/0x480 [11004.055000] [8020d393] show_trace+0x43/0x70 [11004.055000] [8020d3d5] dump_stack+0x15/0x20 [11004.055000] [804b4314] usb_submit_urb+0x224/0x240 [11004.055000] [804b5ff5] usb_sg_wait+0xd5/0x180 [11004.055000] [804cf464] usb_stor_bulk_transfer_sg+0xc4/0x120 [11004.055000] [804cf611] usb_stor_Bulk_transport+0x151/0x2e0 [11004.055000] [804cfb57] usb_stor_invoke_transport+0x37/0x380 [11004.055000] [804ce9f9] usb_stor_transparent_scsi_command+0x9/0x10 [11004.055000] [804d0aea] usb_stor_control_thread+0x18a/0x230 [11004.055000] [8024927d] kthread+0x4d/0x80 [11004.055000] [8020c868] child_rip+0xa/0x12 Alan, you got a bite - reel her in! Thanks for forwarding the message. Unforunately it's a false alarm. As mentioned in the original patch, the test it uses isn't precise. To tell you the truth, I rather think there's not much point in keeping usb-try-to-debug-bug-8561.patch around. Anything seriously wrong that it could catch ought to have shown up long ago. And it is now clear that bug 8561 has nothing to do with this; it is a programming error common to many of the USB serial drivers. (Still waiting to hear back from Paulo Pereira whether the fix to the USB Option driver works...) My vote goes toward reverting usb-try-to-debug-bug-8561.patch. However just to be thorough, for anyone wants to keep it here's an untested patch to remove those false alarms. Alan Stern - Remove some false alarms generated by usb-try-to-debug-bug-8561.patch. Signed-off-by: Alan Stern [EMAIL PROTECTED] --- Index: usb-2.6/drivers/usb/core/message.c === --- usb-2.6.orig/drivers/usb/core/message.c +++ usb-2.6/drivers/usb/core/message.c @@ -404,8 +404,6 @@ int usb_sg_init ( io-urbs [i]-complete = sg_complete; io-urbs [i]-context = io; - io-urbs [i]-status = -EINPROGRESS; - io-urbs [i]-actual_length = 0; /* * Some systems need to revert to PIO when DMA is temporarily - 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/
