Re: 2.6.13-rc3-mm1 (ckrm)
Thanks for your well worded response, Shailabh. Others will have to make further comments and decisions here. You have understood what I had to say, and responded well. I have nothing to add at this point that would help further. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401 - 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.13-rc3-mm1 (ckrm)
Paul Jackson wrote: Sorry for the late response - I just saw this note. Shailabh wrote: So if the current CPU controller implementation is considered too intrusive/unacceptable, it can be reworked or (and we certainly hope not) even rejected in perpetuity. It is certainly reasonable that you would hope such. But this hypothetical possibility concerns me a little. Where would that leave CKRM, if it was in the mainline kernel, but there was no CPU controller in the mainline kernel? It would be unfortunate indeed since CPU is the first resource that people want to try and control. However, I feel the following are also true: 1. It is still better to have CKRM with the I/O, memory, network, forkrate controllers than to have nothing just because the CPU controller is unacceptable. Each controller is useful in its own right. It may not be enough to justify the framework all by itself but together with others (and the possibility of future controllers and per-class metrics), it is sufficient. 2. A CPU controller which is acceptable can be developed. It may not work as well because of the need to keep it simple and not affect the non-CKRM user path, but it will be better than not having anything. Years ago, people said a low-overhead SMP scheduler couldn't be written and they were proved wrong. Currently Ingo is hard at work to make acceptable-impact real time scheduling happen. So why should we rule out the possibility of someone being able to develop a CKRM CPU controller with acceptable impact ? Basically, I'm pointing out that there is no reason to hold the acceptance of the CKRM framework + other controller's hostage to its current CPU controller implementation (or any one controller's implementation for that matter). Wouldn't that be a rather serious problem for many users of CKRM if they wanted to work on mainline kernels? Yes it would. And one could say that its one of the features of the Linux kernel community that they would have to learn to accept. Just like the embedded folks who were rooting for realtime enhancements to be made mainstream for years now, like the RAS folks who have been making a case for better dump/probe tools, and you, who's tried in the past to get the community to accept PAGG/CSA :-) But I don't think we need to be resigned to a CPU controller-less existence quite yet. Using the examples given earlier, realtime is being discussed seriously now and RAS features are getting acceptance. So why should one rule out the possibility of an acceptable CPU controller for CKRM being developed ? We, the current developers of CKRM, hope our current design can be a basis for the "one controller to rule them all" ! But if there are other ways of doing it or people can point out whats wrong with the implementation, it can be reworked or rewritten from scratch. The important thing, as Andrew said, is to get real feedback about what is unacceptable in the current implementation and any ideas on how it can be done better. But lets start off with what has been put out there in -mm rather than getting stuck on discussing something that hasn't been even put out yet ? --Shailabh - 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: HPT370 errors under 2.6.13-rc3-mm1
I experienced this same thing (with an HPT too, I might say), and the
problem seemed to be an underpowered system. Replaced the power supply
and the problem went away.
My box had 7 HDs, all of them worked fine using a different system but I
got these errors when they where together. I thought it was the HTP card
but replacing it didn't help. Turned out it was the PS...
Alan Cox wrote:
On Sad, 2005-07-23 at 14:28 +1200, mdew wrote:
I'm unable to mount an ext2 drive using the hpt370A raid card.
upon mounting the drive, dmesg will spew these errors..I've tried
different cables and drive is fine.
Jul 23 01:30:21 localhost kernel: hdf: dma timeout error: status=0x25
{ DeviceFault CorrectedError Error }
Jul 23 01:30:21 localhost kernel: hdf: dma timeout error: error=0x25 {
DriveStatusError AddrMarkNotFound }, LBAsect=8830589412645,
high=526344, low=2434341, sector=390715711
Your drive disagrees with you. Note that it said
"Device fault"
"Error"
"Drive Status Error"
"Address Mark Not Found"
that came from the drive not the OS.
-
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.13-rc3-mm1 compiles unrequested/unconfigured module!
On Thu, Jul 28, 2005 at 02:50:24PM +0200, Helge Hafting wrote: > I usually compile without module support. This time, I turned modules > on in order to compile an external module. > > To my surprise, drivers/scsi/qla2xxx/qla2xxx.ko were built even though > no actual modules are selected in my .config, and the source is > not patched at all except the mm1 patch. Known bug, alresdy fixed in -mm3. > Helge Hafting 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.13-rc3-mm1 compiles unrequested/unconfigured module!
I usually compile without module support. This time, I turned modules on in order to compile an external module. To my surprise, drivers/scsi/qla2xxx/qla2xxx.ko were built even though no actual modules are selected in my .config, and the source is not patched at all except the mm1 patch. Helge Hafting - 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.13-rc3-mm1 compiles unrequested/unconfigured module!
I usually compile without module support. This time, I turned modules on in order to compile an external module. To my surprise, drivers/scsi/qla2xxx/qla2xxx.ko were built even though no actual modules are selected in my .config, and the source is not patched at all except the mm1 patch. Helge Hafting - 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.13-rc3-mm1 compiles unrequested/unconfigured module!
On Thu, Jul 28, 2005 at 02:50:24PM +0200, Helge Hafting wrote: I usually compile without module support. This time, I turned modules on in order to compile an external module. To my surprise, drivers/scsi/qla2xxx/qla2xxx.ko were built even though no actual modules are selected in my .config, and the source is not patched at all except the mm1 patch. Known bug, alresdy fixed in -mm3. Helge Hafting 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: HPT370 errors under 2.6.13-rc3-mm1
I experienced this same thing (with an HPT too, I might say), and the
problem seemed to be an underpowered system. Replaced the power supply
and the problem went away.
My box had 7 HDs, all of them worked fine using a different system but I
got these errors when they where together. I thought it was the HTP card
but replacing it didn't help. Turned out it was the PS...
Alan Cox wrote:
On Sad, 2005-07-23 at 14:28 +1200, mdew wrote:
I'm unable to mount an ext2 drive using the hpt370A raid card.
upon mounting the drive, dmesg will spew these errors..I've tried
different cables and drive is fine.
Jul 23 01:30:21 localhost kernel: hdf: dma timeout error: status=0x25
{ DeviceFault CorrectedError Error }
Jul 23 01:30:21 localhost kernel: hdf: dma timeout error: error=0x25 {
DriveStatusError AddrMarkNotFound }, LBAsect=8830589412645,
high=526344, low=2434341, sector=390715711
Your drive disagrees with you. Note that it said
Device fault
Error
Drive Status Error
Address Mark Not Found
that came from the drive not the OS.
-
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.13-rc3-mm1 (ckrm)
Paul Jackson wrote: Sorry for the late response - I just saw this note. Shailabh wrote: So if the current CPU controller implementation is considered too intrusive/unacceptable, it can be reworked or (and we certainly hope not) even rejected in perpetuity. It is certainly reasonable that you would hope such. But this hypothetical possibility concerns me a little. Where would that leave CKRM, if it was in the mainline kernel, but there was no CPU controller in the mainline kernel? It would be unfortunate indeed since CPU is the first resource that people want to try and control. However, I feel the following are also true: 1. It is still better to have CKRM with the I/O, memory, network, forkrate controllers than to have nothing just because the CPU controller is unacceptable. Each controller is useful in its own right. It may not be enough to justify the framework all by itself but together with others (and the possibility of future controllers and per-class metrics), it is sufficient. 2. A CPU controller which is acceptable can be developed. It may not work as well because of the need to keep it simple and not affect the non-CKRM user path, but it will be better than not having anything. Years ago, people said a low-overhead SMP scheduler couldn't be written and they were proved wrong. Currently Ingo is hard at work to make acceptable-impact real time scheduling happen. So why should we rule out the possibility of someone being able to develop a CKRM CPU controller with acceptable impact ? Basically, I'm pointing out that there is no reason to hold the acceptance of the CKRM framework + other controller's hostage to its current CPU controller implementation (or any one controller's implementation for that matter). Wouldn't that be a rather serious problem for many users of CKRM if they wanted to work on mainline kernels? Yes it would. And one could say that its one of the features of the Linux kernel community that they would have to learn to accept. Just like the embedded folks who were rooting for realtime enhancements to be made mainstream for years now, like the RAS folks who have been making a case for better dump/probe tools, and you, who's tried in the past to get the community to accept PAGG/CSA :-) But I don't think we need to be resigned to a CPU controller-less existence quite yet. Using the examples given earlier, realtime is being discussed seriously now and RAS features are getting acceptance. So why should one rule out the possibility of an acceptable CPU controller for CKRM being developed ? We, the current developers of CKRM, hope our current design can be a basis for the one controller to rule them all ! But if there are other ways of doing it or people can point out whats wrong with the implementation, it can be reworked or rewritten from scratch. The important thing, as Andrew said, is to get real feedback about what is unacceptable in the current implementation and any ideas on how it can be done better. But lets start off with what has been put out there in -mm rather than getting stuck on discussing something that hasn't been even put out yet ? --Shailabh - 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.13-rc3-mm1 (ckrm)
Thanks for your well worded response, Shailabh. Others will have to make further comments and decisions here. You have understood what I had to say, and responded well. I have nothing to add at this point that would help further. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson [EMAIL PROTECTED] 1.925.600.0401 - 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: [RFC][2.6.13-rc3-mm1] IRQ compression/sharing patch
On Tuesday 26 July 2005 09:03 am, Andi Kleen wrote:
> On Tue, Jul 26, 2005 at 12:12:41AM -0700, James Cleverdon wrote:
> > Here's a patch that builds on Natalie Protasevich's IRQ compression
> > patch and tries to work for MPS boots as well as ACPI. It is meant
> > for a 4-node IBM x460 NUMA box, which was dying because it had
> > interrupt pins with GSI numbers > NR_IRQS and thus overflowed
> > irq_desc.
> >
> > The problem is that this system has 270 GSIs (which are 1:1 mapped
> > with I/O APIC RTEs) and an 8-node box would have 540. This is much
> > bigger than NR_IRQS (224 for both i386 and x86_64). Also, there
> > aren't enough vectors to go around. There are about 190 usable
> > vectors, not counting the reserved ones and the unused vectors at
> > 0x20 to 0x2F. So, my patch attempts to compress the GSI range and
> > share vectors by sharing IRQs.
> >
> > Important safety note: While the SLES 9 version of this patch
> > works, I haven't been able to test the -rc3-mm1 patch enclosed. I
> > keep getting errors from the adp94xx driver. 8-(
> >
> > (Sorry about doing an attachment, but KMail is steadfastly word
> > wrapping inserted files. I need to upgrade)
>
> The patch seems to have lots of unrelated stuff. Can you please
> split it out?
Of course. I'll pull out the BUG_ON()s and some of the other cleanup
stuff into a related patch.
> BTW I plan to implement per CPU IDT vectors similar to Zwane's i386
> patch for x86-64 soon, hopefully with that things will be easier too.
I hope so, too. The problem has been making the most of limited
interrupt resources (vectors and IRQ numbers), when previous coding has
assumed that we could use them lavishly.
> Andrew: this is not 2.6.13 material.
>
> > @@ -276,13 +276,13 @@ config HAVE_DEC_LOCK
> > default y
> >
> > config NR_CPUS
> > - int "Maximum number of CPUs (2-256)"
> > - range 2 256
> > + int "Maximum number of CPUs (2-255)"
> > + range 2 255
> > depends on SMP
> > - default "8"
> > + default "64"
>
> Please don't change that,
Which? The maximum number of addressable CPUs is 255, because FF is
reserved. Or, would you rather the default be 8 or 16? (Hmmm
Dual-core, hyperthreaded CPUs are out. They'll turn a quad box into a
16-way.)
> > +/*
> > + * Check the APIC IDs in MADT table header and choose the APIC
> > mode. + */
> > +void acpi_madt_oem_check(char *oem_id, char *oem_table_id)
> > +{
> > + /* May need to check OEM strings in the future. */
> > +}
> > +
> > +/*
> > + * Check the IDs in MPS header and choose the APIC mode.
> > + */
> > +void mps_oem_check(struct mp_config_table *mpc, char *oem, char
> > *productid) +{
> > + /* May need to check OEM strings in the future. */
> > +}
>
> Can you perhaps add it then later, not now?
Naturally. It was a placeholder for those systems where we can't figure
out what to do using heuristics on the ACPI/MPS table data.
> > +static u8 gsi_2_irq[NR_IRQ_VECTORS] = { [0 ... NR_IRQ_VECTORS-1] =
> > 0xFF };
>
> With the per cpu IDTs we'll likely need more than 8 bits here.
OK, I'll make it u32. Or would you rather have u16?
> > - char str[16];
> > + char oem[9], str[16];
> > int count=sizeof(*mpc);
> > unsigned char *mpt=((unsigned char *)mpc)+count;
> > + extern void mps_oem_check(struct mp_config_table *mpc, char *oem,
> > char *productid);
>
> That would belong in some header if it was needed.
>
> But please just remove it for now.
Right.
> The rest looks ok.
>
> -Andi
Thanks Andi!
--
James Cleverdon
IBM LTC (xSeries Linux Solutions)
{jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot comm
-
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: [RFC][2.6.13-rc3-mm1] IRQ compression/sharing patch
On Tuesday 26 July 2005 09:03 am, Andi Kleen wrote:
On Tue, Jul 26, 2005 at 12:12:41AM -0700, James Cleverdon wrote:
Here's a patch that builds on Natalie Protasevich's IRQ compression
patch and tries to work for MPS boots as well as ACPI. It is meant
for a 4-node IBM x460 NUMA box, which was dying because it had
interrupt pins with GSI numbers NR_IRQS and thus overflowed
irq_desc.
The problem is that this system has 270 GSIs (which are 1:1 mapped
with I/O APIC RTEs) and an 8-node box would have 540. This is much
bigger than NR_IRQS (224 for both i386 and x86_64). Also, there
aren't enough vectors to go around. There are about 190 usable
vectors, not counting the reserved ones and the unused vectors at
0x20 to 0x2F. So, my patch attempts to compress the GSI range and
share vectors by sharing IRQs.
Important safety note: While the SLES 9 version of this patch
works, I haven't been able to test the -rc3-mm1 patch enclosed. I
keep getting errors from the adp94xx driver. 8-(
(Sorry about doing an attachment, but KMail is steadfastly word
wrapping inserted files. I need to upgrade)
The patch seems to have lots of unrelated stuff. Can you please
split it out?
Of course. I'll pull out the BUG_ON()s and some of the other cleanup
stuff into a related patch.
BTW I plan to implement per CPU IDT vectors similar to Zwane's i386
patch for x86-64 soon, hopefully with that things will be easier too.
I hope so, too. The problem has been making the most of limited
interrupt resources (vectors and IRQ numbers), when previous coding has
assumed that we could use them lavishly.
Andrew: this is not 2.6.13 material.
@@ -276,13 +276,13 @@ config HAVE_DEC_LOCK
default y
config NR_CPUS
- int Maximum number of CPUs (2-256)
- range 2 256
+ int Maximum number of CPUs (2-255)
+ range 2 255
depends on SMP
- default 8
+ default 64
Please don't change that,
Which? The maximum number of addressable CPUs is 255, because FF is
reserved. Or, would you rather the default be 8 or 16? (Hmmm
Dual-core, hyperthreaded CPUs are out. They'll turn a quad box into a
16-way.)
+/*
+ * Check the APIC IDs in MADT table header and choose the APIC
mode. + */
+void acpi_madt_oem_check(char *oem_id, char *oem_table_id)
+{
+ /* May need to check OEM strings in the future. */
+}
+
+/*
+ * Check the IDs in MPS header and choose the APIC mode.
+ */
+void mps_oem_check(struct mp_config_table *mpc, char *oem, char
*productid) +{
+ /* May need to check OEM strings in the future. */
+}
Can you perhaps add it then later, not now?
Naturally. It was a placeholder for those systems where we can't figure
out what to do using heuristics on the ACPI/MPS table data.
+static u8 gsi_2_irq[NR_IRQ_VECTORS] = { [0 ... NR_IRQ_VECTORS-1] =
0xFF };
With the per cpu IDTs we'll likely need more than 8 bits here.
OK, I'll make it u32. Or would you rather have u16?
- char str[16];
+ char oem[9], str[16];
int count=sizeof(*mpc);
unsigned char *mpt=((unsigned char *)mpc)+count;
+ extern void mps_oem_check(struct mp_config_table *mpc, char *oem,
char *productid);
That would belong in some header if it was needed.
But please just remove it for now.
Right.
The rest looks ok.
-Andi
Thanks Andi!
--
James Cleverdon
IBM LTC (xSeries Linux Solutions)
{jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot comm
-
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: [RFC][2.6.13-rc3-mm1] IRQ compression/sharing patch
On Tue, Jul 26, 2005 at 12:12:41AM -0700, James Cleverdon wrote:
> Here's a patch that builds on Natalie Protasevich's IRQ compression
> patch and tries to work for MPS boots as well as ACPI. It is meant for
> a 4-node IBM x460 NUMA box, which was dying because it had interrupt
> pins with GSI numbers > NR_IRQS and thus overflowed irq_desc.
>
> The problem is that this system has 270 GSIs (which are 1:1 mapped with
> I/O APIC RTEs) and an 8-node box would have 540. This is much bigger
> than NR_IRQS (224 for both i386 and x86_64). Also, there aren't enough
> vectors to go around. There are about 190 usable vectors, not counting
> the reserved ones and the unused vectors at 0x20 to 0x2F. So, my patch
> attempts to compress the GSI range and share vectors by sharing IRQs.
>
> Important safety note: While the SLES 9 version of this patch works, I
> haven't been able to test the -rc3-mm1 patch enclosed. I keep getting
> errors from the adp94xx driver. 8-(
>
> (Sorry about doing an attachment, but KMail is steadfastly word wrapping
> inserted files. I need to upgrade)
The patch seems to have lots of unrelated stuff. Can you please
split it out?
BTW I plan to implement per CPU IDT vectors similar to Zwane's i386 patch
for x86-64 soon, hopefully with that things will be easier too.
Andrew: this is not 2.6.13 material.
> @@ -276,13 +276,13 @@ config HAVE_DEC_LOCK
> default y
>
> config NR_CPUS
> - int "Maximum number of CPUs (2-256)"
> - range 2 256
> + int "Maximum number of CPUs (2-255)"
> + range 2 255
> depends on SMP
> - default "8"
> + default "64"
Please don't change that,
> +/*
> + * Check the APIC IDs in MADT table header and choose the APIC mode.
> + */
> +void acpi_madt_oem_check(char *oem_id, char *oem_table_id)
> +{
> + /* May need to check OEM strings in the future. */
> +}
> +
> +/*
> + * Check the IDs in MPS header and choose the APIC mode.
> + */
> +void mps_oem_check(struct mp_config_table *mpc, char *oem, char *productid)
> +{
> + /* May need to check OEM strings in the future. */
> +}
Can you perhaps add it then later, not now?
> +static u8 gsi_2_irq[NR_IRQ_VECTORS] = { [0 ... NR_IRQ_VECTORS-1] = 0xFF };
With the per cpu IDTs we'll likely need more than 8 bits here.
> - char str[16];
> + char oem[9], str[16];
> int count=sizeof(*mpc);
> unsigned char *mpt=((unsigned char *)mpc)+count;
> + extern void mps_oem_check(struct mp_config_table *mpc, char *oem, char
> *productid);
That would belong in some header if it was needed.
But please just remove it for now.
The rest looks ok.
-Andi
-
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/
[RFC][2.6.13-rc3-mm1] IRQ compression/sharing patch
Here's a patch that builds on Natalie Protasevich's IRQ compression
patch and tries to work for MPS boots as well as ACPI. It is meant for
a 4-node IBM x460 NUMA box, which was dying because it had interrupt
pins with GSI numbers > NR_IRQS and thus overflowed irq_desc.
The problem is that this system has 270 GSIs (which are 1:1 mapped with
I/O APIC RTEs) and an 8-node box would have 540. This is much bigger
than NR_IRQS (224 for both i386 and x86_64). Also, there aren't enough
vectors to go around. There are about 190 usable vectors, not counting
the reserved ones and the unused vectors at 0x20 to 0x2F. So, my patch
attempts to compress the GSI range and share vectors by sharing IRQs.
Important safety note: While the SLES 9 version of this patch works, I
haven't been able to test the -rc3-mm1 patch enclosed. I keep getting
errors from the adp94xx driver. 8-(
(Sorry about doing an attachment, but KMail is steadfastly word wrapping
inserted files. I need to upgrade)
--
James Cleverdon
IBM LTC (xSeries Linux Solutions)
{jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot comm
diff -pru 2.6.13-rc3-mm1/arch/i386/kernel/acpi/boot.c j13-rc3-mm1/arch/i386/kernel/acpi/boot.c
--- 2.6.13-rc3-mm1/arch/i386/kernel/acpi/boot.c 2005-07-22 18:32:35.0 -0700
+++ j13-rc3-mm1/arch/i386/kernel/acpi/boot.c 2005-07-23 18:32:06.0 -0700
@@ -40,9 +40,10 @@
#ifdef CONFIG_X86_64
-static inline void acpi_madt_oem_check(char *oem_id, char *oem_table_id) { }
+extern void acpi_madt_oem_check(char *oem_id, char *oem_table_id);
extern void __init clustered_apic_check(void);
static inline int ioapic_setup_disabled(void) { return 0; }
+extern int gsi_irq_sharing(int gsi);
#include
#else /* X86 */
@@ -52,6 +53,10 @@ static inline int ioapic_setup_disabled(
#include
#endif /* CONFIG_X86_LOCAL_APIC */
+static inline int ioapic_setup_disabled(void) { return 0; }
+static inline int gsi_irq_sharing(int gsi) { return gsi; }
+
+
#endif /* X86 */
#define BAD_MADT_ENTRY(entry, end) ( \
@@ -480,7 +485,7 @@ int acpi_gsi_to_irq(u32 gsi, unsigned in
*irq = IO_APIC_VECTOR(gsi);
else
#endif
- *irq = gsi;
+ *irq = gsi_irq_sharing(gsi);
return 0;
}
diff -pru 2.6.13-rc3-mm1/arch/x86_64/Kconfig j13-rc3-mm1/arch/x86_64/Kconfig
--- 2.6.13-rc3-mm1/arch/x86_64/Kconfig 2005-07-22 18:32:35.0 -0700
+++ j13-rc3-mm1/arch/x86_64/Kconfig 2005-07-22 18:34:08.0 -0700
@@ -276,13 +276,13 @@ config HAVE_DEC_LOCK
default y
config NR_CPUS
- int "Maximum number of CPUs (2-256)"
- range 2 256
+ int "Maximum number of CPUs (2-255)"
+ range 2 255
depends on SMP
- default "8"
+ default "64"
help
This allows you to specify the maximum number of CPUs which this
- kernel will support. Current maximum is 256 CPUs due to
+ kernel will support. Current maximum is 255 CPUs due to
APIC addressing limits. Less depending on the hardware.
This is purely to save memory - each supported CPU requires
diff -pru 2.6.13-rc3-mm1/arch/x86_64/kernel/genapic.c j13-rc3-mm1/arch/x86_64/kernel/genapic.c
--- 2.6.13-rc3-mm1/arch/x86_64/kernel/genapic.c 2005-07-12 21:46:46.0 -0700
+++ j13-rc3-mm1/arch/x86_64/kernel/genapic.c 2005-07-22 18:34:08.0 -0700
@@ -103,3 +103,19 @@ void send_IPI_self(int vector)
{
__send_IPI_shortcut(APIC_DEST_SELF, vector, APIC_DEST_PHYSICAL);
}
+
+/*
+ * Check the APIC IDs in MADT table header and choose the APIC mode.
+ */
+void acpi_madt_oem_check(char *oem_id, char *oem_table_id)
+{
+ /* May need to check OEM strings in the future. */
+}
+
+/*
+ * Check the IDs in MPS header and choose the APIC mode.
+ */
+void mps_oem_check(struct mp_config_table *mpc, char *oem, char *productid)
+{
+ /* May need to check OEM strings in the future. */
+}
diff -pru 2.6.13-rc3-mm1/arch/x86_64/kernel/io_apic.c j13-rc3-mm1/arch/x86_64/kernel/io_apic.c
--- 2.6.13-rc3-mm1/arch/x86_64/kernel/io_apic.c 2005-07-22 18:32:35.0 -0700
+++ j13-rc3-mm1/arch/x86_64/kernel/io_apic.c 2005-07-23 18:32:40.0 -0700
@@ -56,7 +56,7 @@ int nr_ioapic_registers[MAX_IO_APICS];
* Rough estimation of how many shared IRQs there are, can
* be changed anytime.
*/
-#define MAX_PLUS_SHARED_IRQS NR_IRQS
+#define MAX_PLUS_SHARED_IRQS NR_IRQ_VECTORS
#define PIN_MAP_SIZE (MAX_PLUS_SHARED_IRQS + NR_IRQS)
/*
@@ -84,6 +84,7 @@ int vector_irq[NR_VECTORS] = { [0 ... NR
int pin; \
struct irq_pin_list *entry = irq_2_pin + irq; \
\
+ BUG_ON(irq >= NR_IRQS); \
for (;;) { \
unsigned int reg; \
pin = entry->pin; \
@@ -126,6 +127,8 @@ static void set_ioapic_affinity_irq(unsi
}
#endif
+static u8 gsi_2_irq[NR_IRQ_VECTORS] = { [0 ... NR_IRQ_VECTORS-1] = 0xFF };
+
/*
* The common case is 1:1 IRQ<->pin mappings. Sometimes there are
* shared ISA-space IRQs, so we have to support them. We are super
@@ -136,6 +139,7 @@ static void add_pin_to_irq(unsigned
[RFC][2.6.13-rc3-mm1] IRQ compression/sharing patch
Here's a patch that builds on Natalie Protasevich's IRQ compression
patch and tries to work for MPS boots as well as ACPI. It is meant for
a 4-node IBM x460 NUMA box, which was dying because it had interrupt
pins with GSI numbers NR_IRQS and thus overflowed irq_desc.
The problem is that this system has 270 GSIs (which are 1:1 mapped with
I/O APIC RTEs) and an 8-node box would have 540. This is much bigger
than NR_IRQS (224 for both i386 and x86_64). Also, there aren't enough
vectors to go around. There are about 190 usable vectors, not counting
the reserved ones and the unused vectors at 0x20 to 0x2F. So, my patch
attempts to compress the GSI range and share vectors by sharing IRQs.
Important safety note: While the SLES 9 version of this patch works, I
haven't been able to test the -rc3-mm1 patch enclosed. I keep getting
errors from the adp94xx driver. 8-(
(Sorry about doing an attachment, but KMail is steadfastly word wrapping
inserted files. I need to upgrade)
--
James Cleverdon
IBM LTC (xSeries Linux Solutions)
{jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot comm
diff -pru 2.6.13-rc3-mm1/arch/i386/kernel/acpi/boot.c j13-rc3-mm1/arch/i386/kernel/acpi/boot.c
--- 2.6.13-rc3-mm1/arch/i386/kernel/acpi/boot.c 2005-07-22 18:32:35.0 -0700
+++ j13-rc3-mm1/arch/i386/kernel/acpi/boot.c 2005-07-23 18:32:06.0 -0700
@@ -40,9 +40,10 @@
#ifdef CONFIG_X86_64
-static inline void acpi_madt_oem_check(char *oem_id, char *oem_table_id) { }
+extern void acpi_madt_oem_check(char *oem_id, char *oem_table_id);
extern void __init clustered_apic_check(void);
static inline int ioapic_setup_disabled(void) { return 0; }
+extern int gsi_irq_sharing(int gsi);
#include asm/proto.h
#else /* X86 */
@@ -52,6 +53,10 @@ static inline int ioapic_setup_disabled(
#include mach_mpparse.h
#endif /* CONFIG_X86_LOCAL_APIC */
+static inline int ioapic_setup_disabled(void) { return 0; }
+static inline int gsi_irq_sharing(int gsi) { return gsi; }
+
+
#endif /* X86 */
#define BAD_MADT_ENTRY(entry, end) ( \
@@ -480,7 +485,7 @@ int acpi_gsi_to_irq(u32 gsi, unsigned in
*irq = IO_APIC_VECTOR(gsi);
else
#endif
- *irq = gsi;
+ *irq = gsi_irq_sharing(gsi);
return 0;
}
diff -pru 2.6.13-rc3-mm1/arch/x86_64/Kconfig j13-rc3-mm1/arch/x86_64/Kconfig
--- 2.6.13-rc3-mm1/arch/x86_64/Kconfig 2005-07-22 18:32:35.0 -0700
+++ j13-rc3-mm1/arch/x86_64/Kconfig 2005-07-22 18:34:08.0 -0700
@@ -276,13 +276,13 @@ config HAVE_DEC_LOCK
default y
config NR_CPUS
- int Maximum number of CPUs (2-256)
- range 2 256
+ int Maximum number of CPUs (2-255)
+ range 2 255
depends on SMP
- default 8
+ default 64
help
This allows you to specify the maximum number of CPUs which this
- kernel will support. Current maximum is 256 CPUs due to
+ kernel will support. Current maximum is 255 CPUs due to
APIC addressing limits. Less depending on the hardware.
This is purely to save memory - each supported CPU requires
diff -pru 2.6.13-rc3-mm1/arch/x86_64/kernel/genapic.c j13-rc3-mm1/arch/x86_64/kernel/genapic.c
--- 2.6.13-rc3-mm1/arch/x86_64/kernel/genapic.c 2005-07-12 21:46:46.0 -0700
+++ j13-rc3-mm1/arch/x86_64/kernel/genapic.c 2005-07-22 18:34:08.0 -0700
@@ -103,3 +103,19 @@ void send_IPI_self(int vector)
{
__send_IPI_shortcut(APIC_DEST_SELF, vector, APIC_DEST_PHYSICAL);
}
+
+/*
+ * Check the APIC IDs in MADT table header and choose the APIC mode.
+ */
+void acpi_madt_oem_check(char *oem_id, char *oem_table_id)
+{
+ /* May need to check OEM strings in the future. */
+}
+
+/*
+ * Check the IDs in MPS header and choose the APIC mode.
+ */
+void mps_oem_check(struct mp_config_table *mpc, char *oem, char *productid)
+{
+ /* May need to check OEM strings in the future. */
+}
diff -pru 2.6.13-rc3-mm1/arch/x86_64/kernel/io_apic.c j13-rc3-mm1/arch/x86_64/kernel/io_apic.c
--- 2.6.13-rc3-mm1/arch/x86_64/kernel/io_apic.c 2005-07-22 18:32:35.0 -0700
+++ j13-rc3-mm1/arch/x86_64/kernel/io_apic.c 2005-07-23 18:32:40.0 -0700
@@ -56,7 +56,7 @@ int nr_ioapic_registers[MAX_IO_APICS];
* Rough estimation of how many shared IRQs there are, can
* be changed anytime.
*/
-#define MAX_PLUS_SHARED_IRQS NR_IRQS
+#define MAX_PLUS_SHARED_IRQS NR_IRQ_VECTORS
#define PIN_MAP_SIZE (MAX_PLUS_SHARED_IRQS + NR_IRQS)
/*
@@ -84,6 +84,7 @@ int vector_irq[NR_VECTORS] = { [0 ... NR
int pin; \
struct irq_pin_list *entry = irq_2_pin + irq; \
\
+ BUG_ON(irq = NR_IRQS); \
for (;;) { \
unsigned int reg; \
pin = entry-pin; \
@@ -126,6 +127,8 @@ static void set_ioapic_affinity_irq(unsi
}
#endif
+static u8 gsi_2_irq[NR_IRQ_VECTORS] = { [0 ... NR_IRQ_VECTORS-1] = 0xFF };
+
/*
* The common case is 1:1 IRQ-pin mappings. Sometimes there are
* shared ISA-space IRQs, so we have to support them. We are super
@@ -136,6 +139,7 @@ static void add_pin_to_irq(unsigned int
static int first_free_entry = NR_IRQS
Re: [RFC][2.6.13-rc3-mm1] IRQ compression/sharing patch
On Tue, Jul 26, 2005 at 12:12:41AM -0700, James Cleverdon wrote:
Here's a patch that builds on Natalie Protasevich's IRQ compression
patch and tries to work for MPS boots as well as ACPI. It is meant for
a 4-node IBM x460 NUMA box, which was dying because it had interrupt
pins with GSI numbers NR_IRQS and thus overflowed irq_desc.
The problem is that this system has 270 GSIs (which are 1:1 mapped with
I/O APIC RTEs) and an 8-node box would have 540. This is much bigger
than NR_IRQS (224 for both i386 and x86_64). Also, there aren't enough
vectors to go around. There are about 190 usable vectors, not counting
the reserved ones and the unused vectors at 0x20 to 0x2F. So, my patch
attempts to compress the GSI range and share vectors by sharing IRQs.
Important safety note: While the SLES 9 version of this patch works, I
haven't been able to test the -rc3-mm1 patch enclosed. I keep getting
errors from the adp94xx driver. 8-(
(Sorry about doing an attachment, but KMail is steadfastly word wrapping
inserted files. I need to upgrade)
The patch seems to have lots of unrelated stuff. Can you please
split it out?
BTW I plan to implement per CPU IDT vectors similar to Zwane's i386 patch
for x86-64 soon, hopefully with that things will be easier too.
Andrew: this is not 2.6.13 material.
@@ -276,13 +276,13 @@ config HAVE_DEC_LOCK
default y
config NR_CPUS
- int Maximum number of CPUs (2-256)
- range 2 256
+ int Maximum number of CPUs (2-255)
+ range 2 255
depends on SMP
- default 8
+ default 64
Please don't change that,
+/*
+ * Check the APIC IDs in MADT table header and choose the APIC mode.
+ */
+void acpi_madt_oem_check(char *oem_id, char *oem_table_id)
+{
+ /* May need to check OEM strings in the future. */
+}
+
+/*
+ * Check the IDs in MPS header and choose the APIC mode.
+ */
+void mps_oem_check(struct mp_config_table *mpc, char *oem, char *productid)
+{
+ /* May need to check OEM strings in the future. */
+}
Can you perhaps add it then later, not now?
+static u8 gsi_2_irq[NR_IRQ_VECTORS] = { [0 ... NR_IRQ_VECTORS-1] = 0xFF };
With the per cpu IDTs we'll likely need more than 8 bits here.
- char str[16];
+ char oem[9], str[16];
int count=sizeof(*mpc);
unsigned char *mpt=((unsigned char *)mpc)+count;
+ extern void mps_oem_check(struct mp_config_table *mpc, char *oem, char
*productid);
That would belong in some header if it was needed.
But please just remove it for now.
The rest looks ok.
-Andi
-
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.13-rc3-mm1
Richard Purdie <[EMAIL PROTECTED]> wrote: > > On Fri, 2005-07-15 at 01:36 -0700, Andrew Morton wrote: > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/ > > On the Zaurus I'm seeing a couple of false "BUG: soft lockup detected on > CPU#0!" reports. These didn't show under 2.6.12-mm1 which was the last > -mm kernel I tested. softlockup.c seems identical between these versions > so it looks like some other change has caused this to appear... > > Both of these are triggered from the nand driver. The functions > concerned (nand_wait_ready and nand_read_buf) are known to be slow (they > wait on hardware). OK, thanks. We can stick a touch_softlockup_watchdog() into those two functions to tell them that we know what we're doing. If you have time to write-and-test a patch then please do so - otherwise I'll take an untested shot at it. - 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.13-rc3-mm1
Richard Purdie [EMAIL PROTECTED] wrote: On Fri, 2005-07-15 at 01:36 -0700, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/ On the Zaurus I'm seeing a couple of false BUG: soft lockup detected on CPU#0! reports. These didn't show under 2.6.12-mm1 which was the last -mm kernel I tested. softlockup.c seems identical between these versions so it looks like some other change has caused this to appear... Both of these are triggered from the nand driver. The functions concerned (nand_wait_ready and nand_read_buf) are known to be slow (they wait on hardware). OK, thanks. We can stick a touch_softlockup_watchdog() into those two functions to tell them that we know what we're doing. If you have time to write-and-test a patch then please do so - otherwise I'll take an untested shot at it. - 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.13-rc3-mm1
On Fri, 2005-07-15 at 01:36 -0700, Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/ On the Zaurus I'm seeing a couple of false "BUG: soft lockup detected on CPU#0!" reports. These didn't show under 2.6.12-mm1 which was the last -mm kernel I tested. softlockup.c seems identical between these versions so it looks like some other change has caused this to appear... Both of these are triggered from the nand driver. The functions concerned (nand_wait_ready and nand_read_buf) are known to be slow (they wait on hardware). Richard BUG: soft lockup detected on CPU#0! Pid: 1, comm: swapper CPU: 0 PC is at sharpsl_nand_dev_ready+0x14/0x28 LR is at nand_wait_ready+0x30/0x50 pc : []lr : []Not tainted sp : c034fa24 ip : c034fa34 fp : c034fa30 r10: c3c09400 r9 : c035e890 r8 : c75a r7 : c022533c r6 : c3c09580 r5 : c3c09400 r4 : 8fc3 r3 : c027f0bc r2 : c4856000 r1 : c4856000 r0 : c3c09400 Flags: NzCv IRQs on FIQs on Mode SVC_32 Segment kernel Control: 397F Table: A0004000 DAC: 0017 [] (show_regs+0x0/0x4c) from [] (softlockup_tick +0x7c/0xb0) r4 = C034E000 [] (softlockup_tick+0x0/0xb0) from [] (do_timer +0x278/0x500) r5 = r4 = 0001 [] (do_timer+0x0/0x500) from [] (timer_tick +0xb4/0xf8) [] (timer_tick+0x0/0xf8) from [] (pxa_timer_interrupt+0x48/0xa8) r6 = C034F9DC r5 = C034E000 r4 = F2A0 [] (pxa_timer_interrupt+0x0/0xa8) from [] (__do_irq +0x6c/0xc4) r8 = C034F9DC r7 = r6 = r5 = C034E000 r4 = C0226314 [] (__do_irq+0x0/0xc4) from [] (do_level_IRQ +0x68/0xb8) [] (do_level_IRQ+0x0/0xb8) from [] (asm_do_IRQ +0x54/0x164) r6 = 0400 r5 = F2D0 r4 = [] (asm_do_IRQ+0x0/0x164) from [] (__irq_svc +0x38/0x78) [] (sharpsl_nand_dev_ready+0x0/0x28) from [] (nand_wait_ready+0x30/0x50) [] (nand_wait_ready+0x0/0x50) from [] (nand_command +0x9c/0x1f0) r7 = r6 = C3C09400 r5 = C3C09580 r4 = [] (nand_command+0x0/0x1f0) from [] (nand_do_read_ecc+0x720/0x7c8) r8 = C034FACC r7 = 0200 r6 = C3C09580 r5 = C75A r4 = [] (nand_do_read_ecc+0x0/0x7c8) from [] (nand_read_ecc+0x44/0x4c) [] (nand_read_ecc+0x0/0x4c) from [] (part_read_ecc +0xa4/0xbc) r4 = [] (part_read_ecc+0x0/0xbc) from [] (jffs2_flash_read+0x1fc/0x2b0) r7 = r6 = 011E8B70 r5 = r4 = C034FBF0 [] (jffs2_flash_read+0x0/0x2b0) from [] (jffs2_fill_scan_buf+0x2c/0x4c) [] (jffs2_fill_scan_buf+0x0/0x4c) from [] (jffs2_scan_medium+0x63c/0x1884) r4 = 011E8B7C [] (jffs2_scan_medium+0x0/0x1884) from [] (jffs2_do_mount_fs+0x1bc/0x6cc) [] (jffs2_do_mount_fs+0x0/0x6cc) from [] (jffs2_do_fill_super+0x130/0x2b4) [] (jffs2_do_fill_super+0x0/0x2b4) from [] (jffs2_get_sb_mtd+0xf4/0x134) r8 = 8401 r7 = C3C4B4E0 r6 = C3C4B4FC r5 = C3C4B200 r4 = C3C4B400 [] (jffs2_get_sb_mtd+0x0/0x134) from [] (jffs2_get_sb_mtdnr+0x50/0x5c) [] (jffs2_get_sb_mtdnr+0x0/0x5c) from [] (jffs2_get_sb+0x130/0x1c0) r7 = 8001 r6 = C034FD5C r5 = C3C5 r4 = FFEA [] (jffs2_get_sb+0x0/0x1c0) from [] (do_kern_mount +0x50/0xf4) [] (do_kern_mount+0x0/0xf4) from [] (do_mount +0x3ac/0x650) [] (do_mount+0x0/0x650) from [] (sys_mount +0x9c/0xe8) [] (sys_mount+0x0/0xe8) from [] (mount_block_root +0xb0/0x264) r7 = C0343000 r6 = C034FF54 r5 = C0343006 r4 = C0343000 [] (mount_block_root+0x0/0x264) from [] (mount_root +0x5c/0x6c) [] (mount_root+0x0/0x6c) from [] (prepare_namespace +0x40/0xe4) r5 = C0019C70 r4 = C0019CC0 [] (prepare_namespace+0x0/0xe4) from [] (init +0x190/0x1fc) r5 = C034E000 r4 = C01F5AA0 [] (init+0x0/0x1fc) from [] (do_exit+0x0/0xd8c) r8 = r7 = r6 = r5 = r4 = VFS: Mounted root (jffs2 filesystem) readonly. and BUG: soft lockup detected on CPU#0! Pid: 1063, comm: busybox CPU: 0 PC is at nand_read_buf+0x28/0x3c LR is at 0x100 pc : []lr : [<0100>]Not tainted sp : c355dac8 ip : 003b fp : c355dad4 r10: c3c09400 r9 : c3b20884 r8 : 0002 r7 : r6 : c3c09580 r5 : r4 : c3b20884 r3 : c4856014 r2 : 00d3 r1 : c3b20884 r0 : c3c09580 Flags: Nzcv IRQs on FIQs on Mode SVC_32 Segment user Control: 397F Table: A354C000 DAC: 0015 [] (show_regs+0x0/0x4c) from [] (softlockup_tick +0x7c/0xb0) r4 = C355C000 [] (softlockup_tick+0x0/0xb0) from [] (do_timer +0x278/0x500) r5 = r4 = 0001 [] (do_timer+0x0/0x500) from [] (timer_tick +0xb4/0xf8) [] (timer_tick+0x0/0xf8) from [] (pxa_timer_interrupt+0x48/0xa8) r6 = C355DA80 r5 = C355C000 r4 = F2A0 [] (pxa_timer_interrupt+0x0/0xa8) from [] (__do_irq +0x6c/0xc4) r8 = C355DA80 r7 = r6 = r5 = C355C000 r4 = C0226314 [] (__do_irq+0x0/0xc4) from [] (do_level_IRQ +0x68/0xb8) [] (do_level_IRQ+0x0/0xb8) from [] (asm_do_IRQ +0x54/0x164) r6 = 0400 r5 = F2D0 r4 = [] (asm_do_IRQ+0x0/0x164) from [] (__irq_svc +0x38/0x78) [] (nand_read
Re: 2.6.13-rc3-mm1
On Fri, 2005-07-15 at 01:36 -0700, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/ On the Zaurus I'm seeing a couple of false BUG: soft lockup detected on CPU#0! reports. These didn't show under 2.6.12-mm1 which was the last -mm kernel I tested. softlockup.c seems identical between these versions so it looks like some other change has caused this to appear... Both of these are triggered from the nand driver. The functions concerned (nand_wait_ready and nand_read_buf) are known to be slow (they wait on hardware). Richard BUG: soft lockup detected on CPU#0! Pid: 1, comm: swapper CPU: 0 PC is at sharpsl_nand_dev_ready+0x14/0x28 LR is at nand_wait_ready+0x30/0x50 pc : [c015f15c]lr : [c0159ea4]Not tainted sp : c034fa24 ip : c034fa34 fp : c034fa30 r10: c3c09400 r9 : c035e890 r8 : c75a r7 : c022533c r6 : c3c09580 r5 : c3c09400 r4 : 8fc3 r3 : c027f0bc r2 : c4856000 r1 : c4856000 r0 : c3c09400 Flags: NzCv IRQs on FIQs on Mode SVC_32 Segment kernel Control: 397F Table: A0004000 DAC: 0017 [c001dd38] (show_regs+0x0/0x4c) from [c0059f48] (softlockup_tick +0x7c/0xb0) r4 = C034E000 [c0059ecc] (softlockup_tick+0x0/0xb0) from [c0042198] (do_timer +0x278/0x500) r5 = r4 = 0001 [c0041f20] (do_timer+0x0/0x500) from [c00211ac] (timer_tick +0xb4/0xf8) [c00210f8] (timer_tick+0x0/0xf8) from [c00279a0] (pxa_timer_interrupt+0x48/0xa8) r6 = C034F9DC r5 = C034E000 r4 = F2A0 [c0027958] (pxa_timer_interrupt+0x0/0xa8) from [c001cb60] (__do_irq +0x6c/0xc4) r8 = C034F9DC r7 = r6 = r5 = C034E000 r4 = C0226314 [c001caf4] (__do_irq+0x0/0xc4) from [c001cddc] (do_level_IRQ +0x68/0xb8) [c001cd74] (do_level_IRQ+0x0/0xb8) from [c001ce80] (asm_do_IRQ +0x54/0x164) r6 = 0400 r5 = F2D0 r4 = [c001ce2c] (asm_do_IRQ+0x0/0x164) from [c001b9b8] (__irq_svc +0x38/0x78) [c015f148] (sharpsl_nand_dev_ready+0x0/0x28) from [c0159ea4] (nand_wait_ready+0x30/0x50) [c0159e74] (nand_wait_ready+0x0/0x50) from [c0159f60] (nand_command +0x9c/0x1f0) r7 = r6 = C3C09400 r5 = C3C09580 r4 = [c0159ec4] (nand_command+0x0/0x1f0) from [c015b4b8] (nand_do_read_ecc+0x720/0x7c8) r8 = C034FACC r7 = 0200 r6 = C3C09580 r5 = C75A r4 = [c015ad98] (nand_do_read_ecc+0x0/0x7c8) from [c015b5e8] (nand_read_ecc+0x44/0x4c) [c015b5a4] (nand_read_ecc+0x0/0x4c) from [c0155364] (part_read_ecc +0xa4/0xbc) r4 = [c01552c0] (part_read_ecc+0x0/0xbc) from [c00e5280] (jffs2_flash_read+0x1fc/0x2b0) r7 = r6 = 011E8B70 r5 = r4 = C034FBF0 [c00e5084] (jffs2_flash_read+0x0/0x2b0) from [c00dbd48] (jffs2_fill_scan_buf+0x2c/0x4c) [c00dbd1c] (jffs2_fill_scan_buf+0x0/0x4c) from [c00dc424] (jffs2_scan_medium+0x63c/0x1884) r4 = 011E8B7C [c00dbde8] (jffs2_scan_medium+0x0/0x1884) from [c00e0020] (jffs2_do_mount_fs+0x1bc/0x6cc) [c00dfe64] (jffs2_do_mount_fs+0x0/0x6cc) from [c00e2d60] (jffs2_do_fill_super+0x130/0x2b4) [c00e2c30] (jffs2_do_fill_super+0x0/0x2b4) from [c00e3244] (jffs2_get_sb_mtd+0xf4/0x134) r8 = 8401 r7 = C3C4B4E0 r6 = C3C4B4FC r5 = C3C4B200 r4 = C3C4B400 [c00e3150] (jffs2_get_sb_mtd+0x0/0x134) from [c00e32d4] (jffs2_get_sb_mtdnr+0x50/0x5c) [c00e3284] (jffs2_get_sb_mtdnr+0x0/0x5c) from [c00e3410] (jffs2_get_sb+0x130/0x1c0) r7 = 8001 r6 = C034FD5C r5 = C3C5 r4 = FFEA [c00e32e0] (jffs2_get_sb+0x0/0x1c0) from [c00890d0] (do_kern_mount +0x50/0xf4) [c0089080] (do_kern_mount+0x0/0xf4) from [c00a3de8] (do_mount +0x3ac/0x650) [c00a3a3c] (do_mount+0x0/0x650) from [c00a44c8] (sys_mount +0x9c/0xe8) [c00a442c] (sys_mount+0x0/0xe8) from [c0008b64] (mount_block_root +0xb0/0x264) r7 = C0343000 r6 = C034FF54 r5 = C0343006 r4 = C0343000 [c0008ab4] (mount_block_root+0x0/0x264) from [c0008d74] (mount_root +0x5c/0x6c) [c0008d18] (mount_root+0x0/0x6c) from [c0008dc4] (prepare_namespace +0x40/0xe4) r5 = C0019C70 r4 = C0019CC0 [c0008d84] (prepare_namespace+0x0/0xe4) from [c001b200] (init +0x190/0x1fc) r5 = C034E000 r4 = C01F5AA0 [c001b070] (init+0x0/0x1fc) from [c0039a10] (do_exit+0x0/0xd8c) r8 = r7 = r6 = r5 = r4 = VFS: Mounted root (jffs2 filesystem) readonly. and BUG: soft lockup detected on CPU#0! Pid: 1063, comm: busybox CPU: 0 PC is at nand_read_buf+0x28/0x3c LR is at 0x100 pc : [c0159cb8]lr : [0100]Not tainted sp : c355dac8 ip : 003b fp : c355dad4 r10: c3c09400 r9 : c3b20884 r8 : 0002 r7 : r6 : c3c09580 r5 : r4 : c3b20884 r3 : c4856014 r2 : 00d3 r1 : c3b20884 r0 : c3c09580 Flags: Nzcv IRQs on FIQs on Mode SVC_32 Segment user Control: 397F Table: A354C000 DAC: 0015 [c001dd38] (show_regs+0x0/0x4c) from [c0059f48] (softlockup_tick +0x7c/0xb0) r4 = C355C000 [c0059ecc] (softlockup_tick+0x0/0xb0) from [c0042198] (do_timer +0x278/0x500) r5 = r4 = 0001 [c0041f20] (do_timer+0x0/0x500) from [c00211ac
Re: HPT370 errors under 2.6.13-rc3-mm1
On Sad, 2005-07-23 at 14:28 +1200, mdew wrote:
> I'm unable to mount an ext2 drive using the hpt370A raid card.
>
> upon mounting the drive, dmesg will spew these errors..I've tried
> different cables and drive is fine.
> Jul 23 01:30:21 localhost kernel: hdf: dma timeout error: status=0x25
> { DeviceFault CorrectedError Error }
> Jul 23 01:30:21 localhost kernel: hdf: dma timeout error: error=0x25 {
> DriveStatusError AddrMarkNotFound }, LBAsect=8830589412645,
> high=526344, low=2434341, sector=390715711
Your drive disagrees with you. Note that it said
"Device fault"
"Error"
"Drive Status Error"
"Address Mark Not Found"
that came from the drive not the OS.
-
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: HPT370 errors under 2.6.13-rc3-mm1
On Gwe, 2005-07-22 at 22:47 -0400, Bartlomiej Zolnierkiewicz wrote:
> Hi,
>
> Does vanilla kernel 2.6.12 work for you?
> It doesn't contain hpt366 driver update.
Its nothing to do with the driver. Read the trace Bartlomiej
> > Jul 23 01:30:21 localhost kernel: hdf: dma timeout error: status=0x25
> > { DeviceFault CorrectedError Error }
> > Jul 23 01:30:21 localhost kernel: hdf: dma timeout error: error=0x25 {
> > DriveStatusError AddrMarkNotFound }, LBAsect=8830589412645,
> > high=526344, low=2434341, sector=390715711
It timed out because the drive took a very long time to recover a bad
address mark but was able to do so.
-
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: [ckrm-tech] Re: 2.6.13-rc3-mm1 (ckrm)
> > if CKRM is just extensions, I think it should be an external patch. > > if it provides a path towards unifying the many disparate RM mechanisms > > already in the kernel, great! > > OK, so if it provides a path towards unifying these, what should happen > to the old interfaces when they conflict with those offered by CKRM? I don't think the name matters, as long as the RM code is simplified/unified. that is, the only difference at first would be a change in name - same behavior. > For instance, I'm considering how a per-class (re)nice setting would > work. What should happen when the user (re)nices a process to a > different value than the nice of the process' class? Should CKRM: it has to behave as it does now, unless the admin has imposed some class structure other than the normal POSIX one (ie, nice pertains only to a process and is inherited by future children.) > a) disable the old interface by > i) removing it > ii) return an error when CKRM is active > iii) return an error when CKRM has specified a nice value for the > process via membership in a class > iv) return an error when the (re)nice value is inconsistent with the > nice value assigned to the class some interfaces must remain (renice), and if their behavior is implemented via CKRM, it must, by default, act as before. other interfaces (say overcommit_ratio) probably don't need to remain. > b) trust the user, ignore the class nice value, and allow the new nice > value users can only nice up, and that policy needs to remain, obviously. you appear to be asking what happens when the scope of the old mechanism conflicts with the scope determined by admin-set CKRM classes. I'd say that nicing a single process should change the nice of the whole class that the process is in, if any. otherwise, it acts to rip that process out of the class, which is probably even less 'least surprise'. > This sort of question would probably come up for any other CKRM > "embraced-and-extended" tunables. Should they use the answer to this > one, or would it go on a case-by-case basis? I don't see that CKRM should play by rules different from other kernel improvements - preserve standard/former behavior when that behavior is documented (certainly nice is). in the absense of admin-set classes, nice would behave the same. all CKRM is doing here is providing a broader framework to hang the tunables on. it should be able to express all existing tunables in scope. - 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: HPT370 errors under 2.6.13-rc3-mm1
On Sat, Jul 23, 2005 at 11:50:43PM +1200, mdew wrote: > looks like 2.6.12 does the same sort of thing.. > As a data-point, my dual HPT374 controllers are fine with 2.6.13-rc3-mm1. One onboard, one in a pci-slot in an Epox 4PCA3+ (socket 478, i875 chipset) motherboard. Linux adsl-gate 2.6.13-rc3-mm1 #1 SMP Sat Jul 16 07:13:24 CEST 2005 i686 GNU/Linux Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx HPT374: IDE controller at PCI slot :02:00.0 ACPI: PCI Interrupt :02:00.0[A] -> GSI 16 (level, low) -> IRQ 16 HPT374: chipset revision 7 HPT374: 100% native mode on irq 16 HPT37X: using 33MHz PCI clock ide2: BM-DMA at 0x9400-0x9407, BIOS settings: hde:DMA, hdf:pio HPT37X: using 33MHz PCI clock ide3: BM-DMA at 0x9408-0x940f, BIOS settings: hdg:DMA, hdh:pio ACPI: PCI Interrupt :02:00.1[A] -> GSI 16 (level, low) -> IRQ 16 HPT37X: using 33MHz PCI clock ide4: BM-DMA at 0x9900-0x9907, BIOS settings: hdi:DMA, hdj:pio HPT37X: using 33MHz PCI clock ide5: BM-DMA at 0x9908-0x990f, BIOS settings: hdk:DMA, hdl:pio Probing IDE interface ide2... hde: WDC WD2000JB-00FUA0, ATA DISK drive ide2 at 0x9000-0x9007,0x9102 on irq 16 Probing IDE interface ide3... hdg: WDC WD2500JB-00FUA0, ATA DISK drive ide3 at 0x9200-0x9207,0x9302 on irq 16 Probing IDE interface ide4... hdi: WDC WD2000BB-00DAA1, ATA DISK drive ide4 at 0x9500-0x9507,0x9602 on irq 16 Probing IDE interface ide5... hdk: ST3300831A, ATA DISK drive ide5 at 0x9700-0x9707,0x9802 on irq 16 HPT374: IDE controller at PCI slot :02:05.0 ACPI: PCI Interrupt :02:05.0[A] -> GSI 21 (level, low) -> IRQ 21 HPT374: chipset revision 7 HPT374: 100% native mode on irq 21 HPT37X: using 33MHz PCI clock ide6: BM-DMA at 0x9f00-0x9f07, BIOS settings: hdm:pio, hdn:DMA HPT37X: using 33MHz PCI clock ide7: BM-DMA at 0x9f08-0x9f0f, BIOS settings: hdo:pio, hdp:DMA ACPI: PCI Interrupt :02:05.1[A] -> GSI 21 (level, low) -> IRQ 21 HPT37X: using 33MHz PCI clock ide8: BM-DMA at 0xa400-0xa407, BIOS settings: hdq:DMA, hdr:pio HPT37X: using 33MHz PCI clock ide9: BM-DMA at 0xa408-0xa40f, BIOS settings: hds:pio, hdt:DMA Probing IDE interface ide6... hdn: Maxtor 4A300J0, ATA DISK drive ide6 at 0x9b00-0x9b07,0x9c02 on irq 21 Probing IDE interface ide7... hdp: Maxtor 6Y200P0, ATA DISK drive ide7 at 0x9d00-0x9d07,0x9e02 on irq 21 Probing IDE interface ide8... hdq: WDC WD2500JB-00FUA0, ATA DISK drive ide8 at 0xa000-0xa007,0xa102 on irq 21 Probing IDE interface ide9... hdt: Maxtor 4A300J0, ATA DISK drive ide9 at 0xa200-0xa207,0xa302 on irq 21 hda: max request size: 1024KiB hda: 241254720 sectors (123522 MB) w/7965KiB Cache, CHS=16383/255/63, UDMA(100) hda: cache flushes supported hda: hda1 hda2 hdc: max request size: 1024KiB hdc: 241254720 sectors (123522 MB) w/7965KiB Cache, CHS=16383/255/63, UDMA(100) hdc: cache flushes supported hdc: hdc1 hdc2 hde: max request size: 1024KiB hde: 390721968 sectors (200049 MB) w/8192KiB Cache, CHS=24321/255/63, UDMA(33) hde: cache flushes supported hde: hde1 hdg: max request size: 1024KiB hdg: 488397168 sectors (250059 MB) w/8192KiB Cache, CHS=30401/255/63, UDMA(100) hdg: cache flushes supported hdg: hdg1 hdi: max request size: 1024KiB hdi: 390721968 sectors (200049 MB) w/2048KiB Cache, CHS=24321/255/63, UDMA(100) hdi: cache flushes supported hdi: hdi1 hdk: max request size: 1024KiB hdk: 586072368 sectors (300069 MB) w/8192KiB Cache, CHS=36481/255/63, UDMA(100) hdk: cache flushes supported hdk: hdk1 hdn: max request size: 1024KiB hdn: 585940320 sectors (31 MB) w/2048KiB Cache, CHS=36473/255/63, UDMA(100) hdn: cache flushes supported hdn: hdn1 hdp: max request size: 1024KiB hdp: 398297088 sectors (203928 MB) w/7936KiB Cache, CHS=24792/255/63, UDMA(100) hdp: cache flushes supported hdp: hdp1 hdq: max request size: 1024KiB hdq: 488397168 sectors (250059 MB) w/8192KiB Cache, CHS=30401/255/63, UDMA(100) hdq: cache flushes supported hdq: hdq1 hdt: max request size: 1024KiB hdt: 585940320 sectors (31 MB) w/2048KiB Cache, CHS=36473/255/63, UDMA(100) hdt: cache flushes supported hdt: hdt1 Kind regards, Jurriaan - 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: HPT370 errors under 2.6.13-rc3-mm1
looks like 2.6.12 does the same sort of thing..
On 7/23/05, Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Does vanilla kernel 2.6.12 work for you?
> It doesn't contain hpt366 driver update.
>
> Bartlomiej
>
> On 7/22/05, mdew <[EMAIL PROTECTED]> wrote:
> > I'm unable to mount an ext2 drive using the hpt370A raid card.
> >
> > upon mounting the drive, dmesg will spew these errors..I've tried
> > different cables and drive is fine.
> >
> > Jul 23 01:30:11 localhost kernel: hdf: dma_timer_expiry: dma status == 0x41
> > Jul 23 01:30:21 localhost kernel: hdf: DMA timeout error
> > Jul 23 01:30:21 localhost kernel: hdf: dma timeout error: status=0x25
> > { DeviceFault CorrectedError Error }
> > Jul 23 01:30:21 localhost kernel: hdf: dma timeout error: error=0x25 {
> > DriveStatusError AddrMarkNotFound }, LBAsect=8830589412645,
> > high=526344, low=2434341, sector=390715711
> > Jul 23 01:30:21 localhost kernel: ide: failed opcode was: unknown
> > Jul 23 01:30:21 localhost kernel: hdf: DMA disabled
> > Jul 23 01:30:21 localhost kernel: ide2: reset: master: error (0x0a?)
> > Jul 23 01:30:21 localhost kernel: end_request: I/O error, dev hdf,
> > sector 390715711
> > Jul 23 01:30:21 localhost kernel: end_request: I/O error, dev hdf,
> > sector 390715712
> > [...]
>
-
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: HPT370 errors under 2.6.13-rc3-mm1
looks like 2.6.12 does the same sort of thing..
On 7/23/05, Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] wrote:
Hi,
Does vanilla kernel 2.6.12 work for you?
It doesn't contain hpt366 driver update.
Bartlomiej
On 7/22/05, mdew [EMAIL PROTECTED] wrote:
I'm unable to mount an ext2 drive using the hpt370A raid card.
upon mounting the drive, dmesg will spew these errors..I've tried
different cables and drive is fine.
Jul 23 01:30:11 localhost kernel: hdf: dma_timer_expiry: dma status == 0x41
Jul 23 01:30:21 localhost kernel: hdf: DMA timeout error
Jul 23 01:30:21 localhost kernel: hdf: dma timeout error: status=0x25
{ DeviceFault CorrectedError Error }
Jul 23 01:30:21 localhost kernel: hdf: dma timeout error: error=0x25 {
DriveStatusError AddrMarkNotFound }, LBAsect=8830589412645,
high=526344, low=2434341, sector=390715711
Jul 23 01:30:21 localhost kernel: ide: failed opcode was: unknown
Jul 23 01:30:21 localhost kernel: hdf: DMA disabled
Jul 23 01:30:21 localhost kernel: ide2: reset: master: error (0x0a?)
Jul 23 01:30:21 localhost kernel: end_request: I/O error, dev hdf,
sector 390715711
Jul 23 01:30:21 localhost kernel: end_request: I/O error, dev hdf,
sector 390715712
[...]
-
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: HPT370 errors under 2.6.13-rc3-mm1
On Sat, Jul 23, 2005 at 11:50:43PM +1200, mdew wrote: looks like 2.6.12 does the same sort of thing.. As a data-point, my dual HPT374 controllers are fine with 2.6.13-rc3-mm1. One onboard, one in a pci-slot in an Epox 4PCA3+ (socket 478, i875 chipset) motherboard. Linux adsl-gate 2.6.13-rc3-mm1 #1 SMP Sat Jul 16 07:13:24 CEST 2005 i686 GNU/Linux Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx HPT374: IDE controller at PCI slot :02:00.0 ACPI: PCI Interrupt :02:00.0[A] - GSI 16 (level, low) - IRQ 16 HPT374: chipset revision 7 HPT374: 100% native mode on irq 16 HPT37X: using 33MHz PCI clock ide2: BM-DMA at 0x9400-0x9407, BIOS settings: hde:DMA, hdf:pio HPT37X: using 33MHz PCI clock ide3: BM-DMA at 0x9408-0x940f, BIOS settings: hdg:DMA, hdh:pio ACPI: PCI Interrupt :02:00.1[A] - GSI 16 (level, low) - IRQ 16 HPT37X: using 33MHz PCI clock ide4: BM-DMA at 0x9900-0x9907, BIOS settings: hdi:DMA, hdj:pio HPT37X: using 33MHz PCI clock ide5: BM-DMA at 0x9908-0x990f, BIOS settings: hdk:DMA, hdl:pio Probing IDE interface ide2... hde: WDC WD2000JB-00FUA0, ATA DISK drive ide2 at 0x9000-0x9007,0x9102 on irq 16 Probing IDE interface ide3... hdg: WDC WD2500JB-00FUA0, ATA DISK drive ide3 at 0x9200-0x9207,0x9302 on irq 16 Probing IDE interface ide4... hdi: WDC WD2000BB-00DAA1, ATA DISK drive ide4 at 0x9500-0x9507,0x9602 on irq 16 Probing IDE interface ide5... hdk: ST3300831A, ATA DISK drive ide5 at 0x9700-0x9707,0x9802 on irq 16 HPT374: IDE controller at PCI slot :02:05.0 ACPI: PCI Interrupt :02:05.0[A] - GSI 21 (level, low) - IRQ 21 HPT374: chipset revision 7 HPT374: 100% native mode on irq 21 HPT37X: using 33MHz PCI clock ide6: BM-DMA at 0x9f00-0x9f07, BIOS settings: hdm:pio, hdn:DMA HPT37X: using 33MHz PCI clock ide7: BM-DMA at 0x9f08-0x9f0f, BIOS settings: hdo:pio, hdp:DMA ACPI: PCI Interrupt :02:05.1[A] - GSI 21 (level, low) - IRQ 21 HPT37X: using 33MHz PCI clock ide8: BM-DMA at 0xa400-0xa407, BIOS settings: hdq:DMA, hdr:pio HPT37X: using 33MHz PCI clock ide9: BM-DMA at 0xa408-0xa40f, BIOS settings: hds:pio, hdt:DMA Probing IDE interface ide6... hdn: Maxtor 4A300J0, ATA DISK drive ide6 at 0x9b00-0x9b07,0x9c02 on irq 21 Probing IDE interface ide7... hdp: Maxtor 6Y200P0, ATA DISK drive ide7 at 0x9d00-0x9d07,0x9e02 on irq 21 Probing IDE interface ide8... hdq: WDC WD2500JB-00FUA0, ATA DISK drive ide8 at 0xa000-0xa007,0xa102 on irq 21 Probing IDE interface ide9... hdt: Maxtor 4A300J0, ATA DISK drive ide9 at 0xa200-0xa207,0xa302 on irq 21 hda: max request size: 1024KiB hda: 241254720 sectors (123522 MB) w/7965KiB Cache, CHS=16383/255/63, UDMA(100) hda: cache flushes supported hda: hda1 hda2 hdc: max request size: 1024KiB hdc: 241254720 sectors (123522 MB) w/7965KiB Cache, CHS=16383/255/63, UDMA(100) hdc: cache flushes supported hdc: hdc1 hdc2 hde: max request size: 1024KiB hde: 390721968 sectors (200049 MB) w/8192KiB Cache, CHS=24321/255/63, UDMA(33) hde: cache flushes supported hde: hde1 hdg: max request size: 1024KiB hdg: 488397168 sectors (250059 MB) w/8192KiB Cache, CHS=30401/255/63, UDMA(100) hdg: cache flushes supported hdg: hdg1 hdi: max request size: 1024KiB hdi: 390721968 sectors (200049 MB) w/2048KiB Cache, CHS=24321/255/63, UDMA(100) hdi: cache flushes supported hdi: hdi1 hdk: max request size: 1024KiB hdk: 586072368 sectors (300069 MB) w/8192KiB Cache, CHS=36481/255/63, UDMA(100) hdk: cache flushes supported hdk: hdk1 hdn: max request size: 1024KiB hdn: 585940320 sectors (31 MB) w/2048KiB Cache, CHS=36473/255/63, UDMA(100) hdn: cache flushes supported hdn: hdn1 hdp: max request size: 1024KiB hdp: 398297088 sectors (203928 MB) w/7936KiB Cache, CHS=24792/255/63, UDMA(100) hdp: cache flushes supported hdp: hdp1 hdq: max request size: 1024KiB hdq: 488397168 sectors (250059 MB) w/8192KiB Cache, CHS=30401/255/63, UDMA(100) hdq: cache flushes supported hdq: hdq1 hdt: max request size: 1024KiB hdt: 585940320 sectors (31 MB) w/2048KiB Cache, CHS=36473/255/63, UDMA(100) hdt: cache flushes supported hdt: hdt1 Kind regards, Jurriaan - 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: [ckrm-tech] Re: 2.6.13-rc3-mm1 (ckrm)
if CKRM is just extensions, I think it should be an external patch. if it provides a path towards unifying the many disparate RM mechanisms already in the kernel, great! OK, so if it provides a path towards unifying these, what should happen to the old interfaces when they conflict with those offered by CKRM? I don't think the name matters, as long as the RM code is simplified/unified. that is, the only difference at first would be a change in name - same behavior. For instance, I'm considering how a per-class (re)nice setting would work. What should happen when the user (re)nices a process to a different value than the nice of the process' class? Should CKRM: it has to behave as it does now, unless the admin has imposed some class structure other than the normal POSIX one (ie, nice pertains only to a process and is inherited by future children.) a) disable the old interface by i) removing it ii) return an error when CKRM is active iii) return an error when CKRM has specified a nice value for the process via membership in a class iv) return an error when the (re)nice value is inconsistent with the nice value assigned to the class some interfaces must remain (renice), and if their behavior is implemented via CKRM, it must, by default, act as before. other interfaces (say overcommit_ratio) probably don't need to remain. b) trust the user, ignore the class nice value, and allow the new nice value users can only nice up, and that policy needs to remain, obviously. you appear to be asking what happens when the scope of the old mechanism conflicts with the scope determined by admin-set CKRM classes. I'd say that nicing a single process should change the nice of the whole class that the process is in, if any. otherwise, it acts to rip that process out of the class, which is probably even less 'least surprise'. This sort of question would probably come up for any other CKRM embraced-and-extended tunables. Should they use the answer to this one, or would it go on a case-by-case basis? I don't see that CKRM should play by rules different from other kernel improvements - preserve standard/former behavior when that behavior is documented (certainly nice is). in the absense of admin-set classes, nice would behave the same. all CKRM is doing here is providing a broader framework to hang the tunables on. it should be able to express all existing tunables in scope. - 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: HPT370 errors under 2.6.13-rc3-mm1
On Gwe, 2005-07-22 at 22:47 -0400, Bartlomiej Zolnierkiewicz wrote:
Hi,
Does vanilla kernel 2.6.12 work for you?
It doesn't contain hpt366 driver update.
Its nothing to do with the driver. Read the trace Bartlomiej
Jul 23 01:30:21 localhost kernel: hdf: dma timeout error: status=0x25
{ DeviceFault CorrectedError Error }
Jul 23 01:30:21 localhost kernel: hdf: dma timeout error: error=0x25 {
DriveStatusError AddrMarkNotFound }, LBAsect=8830589412645,
high=526344, low=2434341, sector=390715711
It timed out because the drive took a very long time to recover a bad
address mark but was able to do so.
-
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: HPT370 errors under 2.6.13-rc3-mm1
On Sad, 2005-07-23 at 14:28 +1200, mdew wrote:
I'm unable to mount an ext2 drive using the hpt370A raid card.
upon mounting the drive, dmesg will spew these errors..I've tried
different cables and drive is fine.
Jul 23 01:30:21 localhost kernel: hdf: dma timeout error: status=0x25
{ DeviceFault CorrectedError Error }
Jul 23 01:30:21 localhost kernel: hdf: dma timeout error: error=0x25 {
DriveStatusError AddrMarkNotFound }, LBAsect=8830589412645,
high=526344, low=2434341, sector=390715711
Your drive disagrees with you. Note that it said
Device fault
Error
Drive Status Error
Address Mark Not Found
that came from the drive not the OS.
-
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: [ckrm-tech] Re: 2.6.13-rc3-mm1 (ckrm)
On Fri, 2005-07-22 at 20:23 -0400, Mark Hahn wrote: > > > actually, let me also say that CKRM is on a continuum that includes > > > current (global) /proc tuning for various subsystems, ulimits, and > > > at the other end, Xen/VMM's. it's conceivable that CKRM could wind up > > > being useful and fast enough to subsume the current global and per-proc > > > tunables. after all, there are MANY places where the kernel tries to > > > maintain some sort of context to allow it to tune/throttle/readahead > > > based on some process-linked context. "embracing and extending" > > > those could make CKRM attractive to people outside the mainframe market. > > > > Seems like an excellent suggestion to me! Yeah, it may be possible to > > maintain the context the kernel keeps on a per-class basis instead of > > globally or per-process. > > right, but are the CKRM people ready to take this on? for instance, > I just grepped 'throttle' in kernel/mm and found a per-task RM in > page-writeback.c. it even has a vaguely class-oriented logic, since > it exempts RT tasks. if CKRM can become a way to make this stuff > cleaner and more effective (again, for normal tasks), then great. > but bolting on a big new different, intrusive mechanism that slows > down all normal jobs by 3% just so someone can run 10K mostly-idle > guests on a giant Power box, well, that's gross. > > > The real question is what constitutes a useful > > "extension" :). > > if CKRM is just extensions, I think it should be an external patch. > if it provides a path towards unifying the many disparate RM mechanisms > already in the kernel, great! OK, so if it provides a path towards unifying these, what should happen to the old interfaces when they conflict with those offered by CKRM? For instance, I'm considering how a per-class (re)nice setting would work. What should happen when the user (re)nices a process to a different value than the nice of the process' class? Should CKRM: a) disable the old interface by i) removing it ii) return an error when CKRM is active iii) return an error when CKRM has specified a nice value for the process via membership in a class iv) return an error when the (re)nice value is inconsistent with the nice value assigned to the class b) trust the user, ignore the class nice value, and allow the new nice value I'd be tempted to do a.iv but it would require some modifications to a system call. b probably wouldn't require any modifications to non-CKRM files/dirs. This sort of question would probably come up for any other CKRM "embraced-and-extended" tunables. Should they use the answer to this one, or would it go on a case-by-case basis? Thanks, -Matt Helsley - 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: HPT370 errors under 2.6.13-rc3-mm1
Hi,
Does vanilla kernel 2.6.12 work for you?
It doesn't contain hpt366 driver update.
Bartlomiej
On 7/22/05, mdew <[EMAIL PROTECTED]> wrote:
> I'm unable to mount an ext2 drive using the hpt370A raid card.
>
> upon mounting the drive, dmesg will spew these errors..I've tried
> different cables and drive is fine.
>
> Jul 23 01:30:11 localhost kernel: hdf: dma_timer_expiry: dma status == 0x41
> Jul 23 01:30:21 localhost kernel: hdf: DMA timeout error
> Jul 23 01:30:21 localhost kernel: hdf: dma timeout error: status=0x25
> { DeviceFault CorrectedError Error }
> Jul 23 01:30:21 localhost kernel: hdf: dma timeout error: error=0x25 {
> DriveStatusError AddrMarkNotFound }, LBAsect=8830589412645,
> high=526344, low=2434341, sector=390715711
> Jul 23 01:30:21 localhost kernel: ide: failed opcode was: unknown
> Jul 23 01:30:21 localhost kernel: hdf: DMA disabled
> Jul 23 01:30:21 localhost kernel: ide2: reset: master: error (0x0a?)
> Jul 23 01:30:21 localhost kernel: end_request: I/O error, dev hdf,
> sector 390715711
> Jul 23 01:30:21 localhost kernel: end_request: I/O error, dev hdf,
> sector 390715712
> [...]
-
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: [ckrm-tech] Re: 2.6.13-rc3-mm1 (ckrm)
> > actually, let me also say that CKRM is on a continuum that includes > > current (global) /proc tuning for various subsystems, ulimits, and > > at the other end, Xen/VMM's. it's conceivable that CKRM could wind up > > being useful and fast enough to subsume the current global and per-proc > > tunables. after all, there are MANY places where the kernel tries to > > maintain some sort of context to allow it to tune/throttle/readahead > > based on some process-linked context. "embracing and extending" > > those could make CKRM attractive to people outside the mainframe market. > > Seems like an excellent suggestion to me! Yeah, it may be possible to > maintain the context the kernel keeps on a per-class basis instead of > globally or per-process. right, but are the CKRM people ready to take this on? for instance, I just grepped 'throttle' in kernel/mm and found a per-task RM in page-writeback.c. it even has a vaguely class-oriented logic, since it exempts RT tasks. if CKRM can become a way to make this stuff cleaner and more effective (again, for normal tasks), then great. but bolting on a big new different, intrusive mechanism that slows down all normal jobs by 3% just so someone can run 10K mostly-idle guests on a giant Power box, well, that's gross. > The real question is what constitutes a useful > "extension" :). if CKRM is just extensions, I think it should be an external patch. if it provides a path towards unifying the many disparate RM mechanisms already in the kernel, great! > I was thinking that per-class nice values might be a good place to > start as well. One advantage of per-class as opposed to per-process nice > is the class is less transient than the process since its lifetime is > determined solely by the system administrator. but the Linux RM needs to subsume traditional Unix process groups, and inherited nice/schd class, and even CAP_ stuff. I think CKRM could start to do this, since classes are very general. but merely adding a new, incompatible feature is just Not A Good Idea. regards, mark hahn. - 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: [ckrm-tech] Re: 2.6.13-rc3-mm1 (ckrm)
On Fri, 2005-07-22 at 12:35 -0400, Mark Hahn wrote: > actually, let me also say that CKRM is on a continuum that includes > current (global) /proc tuning for various subsystems, ulimits, and > at the other end, Xen/VMM's. it's conceivable that CKRM could wind up > being useful and fast enough to subsume the current global and per-proc > tunables. after all, there are MANY places where the kernel tries to > maintain some sort of context to allow it to tune/throttle/readahead > based on some process-linked context. "embracing and extending" > those could make CKRM attractive to people outside the mainframe market. Seems like an excellent suggestion to me! Yeah, it may be possible to maintain the context the kernel keeps on a per-class basis instead of globally or per-process. The real question is what constitutes a useful "extension" :). I was thinking that per-class nice values might be a good place to start as well. One advantage of per-class as opposed to per-process nice is the class is less transient than the process since its lifetime is determined solely by the system administrator. CKRM calls this kind of module a "resource controller". There's a small HOWTO on writing resource controllers here: http://ckrm.sourceforge.net/ckrm-controller-howto.txt If anyone wants to investigate writing such a controller please feel free to ask questions or send HOWTO feedback on the CKRM-Tech mailing list at . Thanks, -Matt Helsley - 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.13-rc3-mm1 (ckrm)
Shailabh wrote: > So if the current CPU controller > implementation is considered too intrusive/unacceptable, it can be > reworked or (and we certainly hope not) even rejected in perpetuity. It is certainly reasonable that you would hope such. But this hypothetical possibility concerns me a little. Where would that leave CKRM, if it was in the mainline kernel, but there was no CPU controller in the mainline kernel? Wouldn't that be a rather serious problem for many users of CKRM if they wanted to work on mainline kernels? -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401 - 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.13-rc3-mm1 (ckrm)
On Gwe, 2005-07-22 at 12:35 -0400, Mark Hahn wrote: > I imagine you, like me, are currently sitting in the Xen talk, Out by a few thousand miles ;) > and I don't believe they are or will do anything so dumb as to throw away > or lose information. yes, in principle, the logic will need to be They don't have it in the first place. > somewhere, and I'm suggesting that the virtualization logic should > be in VMM-only code so it has literally zero effect on host-native > processes. *or* the host-native fast-path. I don't see why you are concerned. If the CKRM=n path is zero impact then its irrelevant to you. Its more expensive to do a lot of resource management at the VMM level because the virtualisation engine doesn't know anything but its getting indications someone wants to be bigger/smaller. > but to really do CKRM, you are going to want quite extensive interaction with > the scheduler, VM page replacement policies, etc. all incredibly > performance-sensitive areas. Bingo - and areas the virtualiser can't see into, at least not unless it uses the same hooks CKRM uses 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.13-rc3-mm1 (ckrm)
> > > the fast path slower and less maintainable. if you are really concerned > > > about isolating many competing servers on a single piece of hardware, then > > > run separate virtualized environments, each with its own user-space. > > > > And the virtualisation layer has to do the same job with less > > information. That to me implies that the virtualisation case is likely > > to be materially less efficient, its just the inefficiency you are > > worried about is hidden in a different pieces of code. I imagine you, like me, are currently sitting in the Xen talk, and I don't believe they are or will do anything so dumb as to throw away or lose information. yes, in principle, the logic will need to be somewhere, and I'm suggesting that the virtualization logic should be in VMM-only code so it has literally zero effect on host-native processes. *or* the host-native fast-path. > > Secondly a lot of this doesnt matter if CKRM=n compiles to no code > > anyway > > I'm actually trying to keep the impact of CKRM=y to near-zero, ergo > only an impact if you create classes. And even then, the goal is to > keep that impact pretty small as well. but to really do CKRM, you are going to want quite extensive interaction with the scheduler, VM page replacement policies, etc. all incredibly performance-sensitive areas. actually, let me also say that CKRM is on a continuum that includes current (global) /proc tuning for various subsystems, ulimits, and at the other end, Xen/VMM's. it's conceivable that CKRM could wind up being useful and fast enough to subsume the current global and per-proc tunables. after all, there are MANY places where the kernel tries to maintain some sort of context to allow it to tune/throttle/readahead based on some process-linked context. "embracing and extending" those could make CKRM attractive to people outside the mainframe market. > Plus you won't have to manage each operating system instance which > can grow into a pain under virtualization. But I still maintain that > both have their place. CKRM may have its place in an externally-maintained patch ;) regards, mark hahn. - 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.13-rc3-mm1 (ckrm)
On Fri, 22 Jul 2005 15:53:55 BST, Alan Cox wrote: > On Gwe, 2005-07-22 at 00:53 -0400, Mark Hahn wrote: > > the fast path slower and less maintainable. if you are really concerned > > about isolating many competing servers on a single piece of hardware, then > > run separate virtualized environments, each with its own user-space. > > And the virtualisation layer has to do the same job with less > information. That to me implies that the virtualisation case is likely > to be materially less efficient, its just the inefficiency you are > worried about is hidden in a different pieces of code. > > Secondly a lot of this doesnt matter if CKRM=n compiles to no code > anyway I'm actually trying to keep the impact of CKRM=y to near-zero, ergo only an impact if you create classes. And even then, the goal is to keep that impact pretty small as well. And yes, a hypervisor does have a lot more overhead in many forms. Something like an overall 2-3% everywhere, where the CKRM impact is likely to be so small as to be hard to measure in the individual subsystems, and overall performance impact should be even smaller. Plus you won't have to manage each operating system instance which can grow into a pain under virtualization. But I still maintain that both have their place. gerrit - 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.13-rc3-mm1 (ckrm)
On Gwe, 2005-07-22 at 00:53 -0400, Mark Hahn wrote: > the fast path slower and less maintainable. if you are really concerned > about isolating many competing servers on a single piece of hardware, then > run separate virtualized environments, each with its own user-space. And the virtualisation layer has to do the same job with less information. That to me implies that the virtualisation case is likely to be materially less efficient, its just the inefficiency you are worried about is hidden in a different pieces of code. Secondly a lot of this doesnt matter if CKRM=n compiles to no code anyway - 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.13-rc3-mm1 (ckrm)
On Gwe, 2005-07-22 at 00:53 -0400, Mark Hahn wrote: the fast path slower and less maintainable. if you are really concerned about isolating many competing servers on a single piece of hardware, then run separate virtualized environments, each with its own user-space. And the virtualisation layer has to do the same job with less information. That to me implies that the virtualisation case is likely to be materially less efficient, its just the inefficiency you are worried about is hidden in a different pieces of code. Secondly a lot of this doesnt matter if CKRM=n compiles to no code anyway - 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.13-rc3-mm1 (ckrm)
On Fri, 22 Jul 2005 15:53:55 BST, Alan Cox wrote: On Gwe, 2005-07-22 at 00:53 -0400, Mark Hahn wrote: the fast path slower and less maintainable. if you are really concerned about isolating many competing servers on a single piece of hardware, then run separate virtualized environments, each with its own user-space. And the virtualisation layer has to do the same job with less information. That to me implies that the virtualisation case is likely to be materially less efficient, its just the inefficiency you are worried about is hidden in a different pieces of code. Secondly a lot of this doesnt matter if CKRM=n compiles to no code anyway I'm actually trying to keep the impact of CKRM=y to near-zero, ergo only an impact if you create classes. And even then, the goal is to keep that impact pretty small as well. And yes, a hypervisor does have a lot more overhead in many forms. Something like an overall 2-3% everywhere, where the CKRM impact is likely to be so small as to be hard to measure in the individual subsystems, and overall performance impact should be even smaller. Plus you won't have to manage each operating system instance which can grow into a pain under virtualization. But I still maintain that both have their place. gerrit - 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.13-rc3-mm1 (ckrm)
the fast path slower and less maintainable. if you are really concerned about isolating many competing servers on a single piece of hardware, then run separate virtualized environments, each with its own user-space. And the virtualisation layer has to do the same job with less information. That to me implies that the virtualisation case is likely to be materially less efficient, its just the inefficiency you are worried about is hidden in a different pieces of code. I imagine you, like me, are currently sitting in the Xen talk, and I don't believe they are or will do anything so dumb as to throw away or lose information. yes, in principle, the logic will need to be somewhere, and I'm suggesting that the virtualization logic should be in VMM-only code so it has literally zero effect on host-native processes. *or* the host-native fast-path. Secondly a lot of this doesnt matter if CKRM=n compiles to no code anyway I'm actually trying to keep the impact of CKRM=y to near-zero, ergo only an impact if you create classes. And even then, the goal is to keep that impact pretty small as well. but to really do CKRM, you are going to want quite extensive interaction with the scheduler, VM page replacement policies, etc. all incredibly performance-sensitive areas. actually, let me also say that CKRM is on a continuum that includes current (global) /proc tuning for various subsystems, ulimits, and at the other end, Xen/VMM's. it's conceivable that CKRM could wind up being useful and fast enough to subsume the current global and per-proc tunables. after all, there are MANY places where the kernel tries to maintain some sort of context to allow it to tune/throttle/readahead based on some process-linked context. embracing and extending those could make CKRM attractive to people outside the mainframe market. Plus you won't have to manage each operating system instance which can grow into a pain under virtualization. But I still maintain that both have their place. CKRM may have its place in an externally-maintained patch ;) regards, mark hahn. - 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.13-rc3-mm1 (ckrm)
On Gwe, 2005-07-22 at 12:35 -0400, Mark Hahn wrote: I imagine you, like me, are currently sitting in the Xen talk, Out by a few thousand miles ;) and I don't believe they are or will do anything so dumb as to throw away or lose information. yes, in principle, the logic will need to be They don't have it in the first place. somewhere, and I'm suggesting that the virtualization logic should be in VMM-only code so it has literally zero effect on host-native processes. *or* the host-native fast-path. I don't see why you are concerned. If the CKRM=n path is zero impact then its irrelevant to you. Its more expensive to do a lot of resource management at the VMM level because the virtualisation engine doesn't know anything but its getting indications someone wants to be bigger/smaller. but to really do CKRM, you are going to want quite extensive interaction with the scheduler, VM page replacement policies, etc. all incredibly performance-sensitive areas. Bingo - and areas the virtualiser can't see into, at least not unless it uses the same hooks CKRM uses 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.13-rc3-mm1 (ckrm)
Shailabh wrote: So if the current CPU controller implementation is considered too intrusive/unacceptable, it can be reworked or (and we certainly hope not) even rejected in perpetuity. It is certainly reasonable that you would hope such. But this hypothetical possibility concerns me a little. Where would that leave CKRM, if it was in the mainline kernel, but there was no CPU controller in the mainline kernel? Wouldn't that be a rather serious problem for many users of CKRM if they wanted to work on mainline kernels? -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson [EMAIL PROTECTED] 1.925.600.0401 - 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: [ckrm-tech] Re: 2.6.13-rc3-mm1 (ckrm)
On Fri, 2005-07-22 at 12:35 -0400, Mark Hahn wrote: snip actually, let me also say that CKRM is on a continuum that includes current (global) /proc tuning for various subsystems, ulimits, and at the other end, Xen/VMM's. it's conceivable that CKRM could wind up being useful and fast enough to subsume the current global and per-proc tunables. after all, there are MANY places where the kernel tries to maintain some sort of context to allow it to tune/throttle/readahead based on some process-linked context. embracing and extending those could make CKRM attractive to people outside the mainframe market. Seems like an excellent suggestion to me! Yeah, it may be possible to maintain the context the kernel keeps on a per-class basis instead of globally or per-process. The real question is what constitutes a useful extension :). I was thinking that per-class nice values might be a good place to start as well. One advantage of per-class as opposed to per-process nice is the class is less transient than the process since its lifetime is determined solely by the system administrator. CKRM calls this kind of module a resource controller. There's a small HOWTO on writing resource controllers here: http://ckrm.sourceforge.net/ckrm-controller-howto.txt If anyone wants to investigate writing such a controller please feel free to ask questions or send HOWTO feedback on the CKRM-Tech mailing list at ckrm-tech@lists.sourceforge.net. Thanks, -Matt Helsley - 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: [ckrm-tech] Re: 2.6.13-rc3-mm1 (ckrm)
actually, let me also say that CKRM is on a continuum that includes current (global) /proc tuning for various subsystems, ulimits, and at the other end, Xen/VMM's. it's conceivable that CKRM could wind up being useful and fast enough to subsume the current global and per-proc tunables. after all, there are MANY places where the kernel tries to maintain some sort of context to allow it to tune/throttle/readahead based on some process-linked context. embracing and extending those could make CKRM attractive to people outside the mainframe market. Seems like an excellent suggestion to me! Yeah, it may be possible to maintain the context the kernel keeps on a per-class basis instead of globally or per-process. right, but are the CKRM people ready to take this on? for instance, I just grepped 'throttle' in kernel/mm and found a per-task RM in page-writeback.c. it even has a vaguely class-oriented logic, since it exempts RT tasks. if CKRM can become a way to make this stuff cleaner and more effective (again, for normal tasks), then great. but bolting on a big new different, intrusive mechanism that slows down all normal jobs by 3% just so someone can run 10K mostly-idle guests on a giant Power box, well, that's gross. The real question is what constitutes a useful extension :). if CKRM is just extensions, I think it should be an external patch. if it provides a path towards unifying the many disparate RM mechanisms already in the kernel, great! I was thinking that per-class nice values might be a good place to start as well. One advantage of per-class as opposed to per-process nice is the class is less transient than the process since its lifetime is determined solely by the system administrator. but the Linux RM needs to subsume traditional Unix process groups, and inherited nice/schd class, and even CAP_ stuff. I think CKRM could start to do this, since classes are very general. but merely adding a new, incompatible feature is just Not A Good Idea. regards, mark hahn. - 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: HPT370 errors under 2.6.13-rc3-mm1
Hi,
Does vanilla kernel 2.6.12 work for you?
It doesn't contain hpt366 driver update.
Bartlomiej
On 7/22/05, mdew [EMAIL PROTECTED] wrote:
I'm unable to mount an ext2 drive using the hpt370A raid card.
upon mounting the drive, dmesg will spew these errors..I've tried
different cables and drive is fine.
Jul 23 01:30:11 localhost kernel: hdf: dma_timer_expiry: dma status == 0x41
Jul 23 01:30:21 localhost kernel: hdf: DMA timeout error
Jul 23 01:30:21 localhost kernel: hdf: dma timeout error: status=0x25
{ DeviceFault CorrectedError Error }
Jul 23 01:30:21 localhost kernel: hdf: dma timeout error: error=0x25 {
DriveStatusError AddrMarkNotFound }, LBAsect=8830589412645,
high=526344, low=2434341, sector=390715711
Jul 23 01:30:21 localhost kernel: ide: failed opcode was: unknown
Jul 23 01:30:21 localhost kernel: hdf: DMA disabled
Jul 23 01:30:21 localhost kernel: ide2: reset: master: error (0x0a?)
Jul 23 01:30:21 localhost kernel: end_request: I/O error, dev hdf,
sector 390715711
Jul 23 01:30:21 localhost kernel: end_request: I/O error, dev hdf,
sector 390715712
[...]
-
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: [ckrm-tech] Re: 2.6.13-rc3-mm1 (ckrm)
On Fri, 2005-07-22 at 20:23 -0400, Mark Hahn wrote: actually, let me also say that CKRM is on a continuum that includes current (global) /proc tuning for various subsystems, ulimits, and at the other end, Xen/VMM's. it's conceivable that CKRM could wind up being useful and fast enough to subsume the current global and per-proc tunables. after all, there are MANY places where the kernel tries to maintain some sort of context to allow it to tune/throttle/readahead based on some process-linked context. embracing and extending those could make CKRM attractive to people outside the mainframe market. Seems like an excellent suggestion to me! Yeah, it may be possible to maintain the context the kernel keeps on a per-class basis instead of globally or per-process. right, but are the CKRM people ready to take this on? for instance, I just grepped 'throttle' in kernel/mm and found a per-task RM in page-writeback.c. it even has a vaguely class-oriented logic, since it exempts RT tasks. if CKRM can become a way to make this stuff cleaner and more effective (again, for normal tasks), then great. but bolting on a big new different, intrusive mechanism that slows down all normal jobs by 3% just so someone can run 10K mostly-idle guests on a giant Power box, well, that's gross. The real question is what constitutes a useful extension :). if CKRM is just extensions, I think it should be an external patch. if it provides a path towards unifying the many disparate RM mechanisms already in the kernel, great! OK, so if it provides a path towards unifying these, what should happen to the old interfaces when they conflict with those offered by CKRM? For instance, I'm considering how a per-class (re)nice setting would work. What should happen when the user (re)nices a process to a different value than the nice of the process' class? Should CKRM: a) disable the old interface by i) removing it ii) return an error when CKRM is active iii) return an error when CKRM has specified a nice value for the process via membership in a class iv) return an error when the (re)nice value is inconsistent with the nice value assigned to the class b) trust the user, ignore the class nice value, and allow the new nice value I'd be tempted to do a.iv but it would require some modifications to a system call. b probably wouldn't require any modifications to non-CKRM files/dirs. This sort of question would probably come up for any other CKRM embraced-and-extended tunables. Should they use the answer to this one, or would it go on a case-by-case basis? Thanks, -Matt Helsley - 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.13-rc3-mm1 (ckrm)
> of the various environments. I don't think you are one of those end > users, though. I don't think I'm required to make everyone happy all > the time. ;) the issue is whether CKRM (in it's real form, not this thin edge) will noticably hurt Linux's fast-path. - 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.13-rc3-mm1 (ckrm)
On Fri, 22 Jul 2005 00:53:58 EDT, Mark Hahn wrote: > > > > yes, that's the crux. CKRM is all about resolving conflicting resource > > > > demands in a multi-user, multi-server, multi-purpose machine. this is > > > > a > > > > huge undertaking, and I'd argue that it's completely inappropriate for > > > > *most* servers. that is, computers are generally so damn cheap that > > > > the clear trend is towards dedicating a machine to a specific purpose, > > > > rather than running eg, shell/MUA/MTA/FS/DB/etc all on a single > > > > machine. > > > > This is a big NAK - if computers are so damn cheap, why is virtualization > > and consolidation such a big deal? Well, the answer is actually that > > yes, you did miss my point. I'm actually arguing that it's bad design > to attempt to arbitrate within a single shared user-space. you make > the fast path slower and less maintainable. if you are really concerned > about isolating many competing servers on a single piece of hardware, then > run separate virtualized environments, each with its own user-space. I'm willing to agree to disagree. I'm in favor of full virtualization as well, as it is appropriate to certain styles of workloads. I also have enough end users who also want to share user level, share tasks, yet also have some level of balancing between the resource consumption of the various environments. I don't think you are one of those end users, though. I don't think I'm required to make everyone happy all the time. ;) BTW, does your mailer purposefully remove cc:'s? Seems like that is normally considered impolite. gerrit - 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.13-rc3-mm1 (ckrm)
> > > yes, that's the crux. CKRM is all about resolving conflicting resource > > > demands in a multi-user, multi-server, multi-purpose machine. this is a > > > huge undertaking, and I'd argue that it's completely inappropriate for > > > *most* servers. that is, computers are generally so damn cheap that > > > the clear trend is towards dedicating a machine to a specific purpose, > > > rather than running eg, shell/MUA/MTA/FS/DB/etc all on a single machine. > > This is a big NAK - if computers are so damn cheap, why is virtualization > and consolidation such a big deal? Well, the answer is actually that yes, you did miss my point. I'm actually arguing that it's bad design to attempt to arbitrate within a single shared user-space. you make the fast path slower and less maintainable. if you are really concerned about isolating many competing servers on a single piece of hardware, then run separate virtualized environments, each with its own user-space. - 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.13-rc3-mm1 (ckrm)
Sorry - I didn't see Mark's original comment, so I'm replying to a reply which I did get. ;-) On Thu, 21 Jul 2005 23:59:09 EDT, Shailabh Nagar wrote: > Mark Hahn wrote: > >>I suspect that the main problem is that this patch is not a mainstream > >>kernel feature that will gain multiple uses, but rather provides > >>support for a specific vendor middleware product used by that > >>vendor and a few closely allied vendors. If it were smaller or > >>less intrusive, such as a driver, this would not be a big problem. > >>That's not the case. > > > > > > yes, that's the crux. CKRM is all about resolving conflicting resource > > demands in a multi-user, multi-server, multi-purpose machine. this is a > > huge undertaking, and I'd argue that it's completely inappropriate for > > *most* servers. that is, computers are generally so damn cheap that > > the clear trend is towards dedicating a machine to a specific purpose, > > rather than running eg, shell/MUA/MTA/FS/DB/etc all on a single machine. This is a big NAK - if computers are so damn cheap, why is virtualization and consolidation such a big deal? Well, the answer is actually that floor space, heat, and power are also continuing to be very important in the overall equation. And, buying machines which are dedicated but often 80-99% idle occasionally bothers people who are concerned about wasting planetary resources for no good reason. Yeah, we can stamp out thousands of metal boxes, but if just a couple can do the same work, well, let's consolidate. Less wasted metal, less wasted heat, less wasted power, less air conditioning, wow, we are now part of the eco-computing movement! ;-) > > this is *directly* in conflict with certain prominent products, such as > > the Altix and various less-prominent Linux-based mainframes. they're all > > about partitioning/virtualization - the big-iron aesthetic of splitting up > > a single machine. note that it's not just about "big", since cluster-based > > approaches can clearly scale far past big-iron, and are in effect statically > > partitioned. yes, buying a hideously expensive single box, and then > > chopping > > it into little pieces is more than a little bizarre, and is mainly based > > on a couple assumptions: Well, yeah IBM has been doing this virtualization & partitioning stuff for ages at lots of different levels for lots of reasons. If we are in such direct conflict with Altix, aren't we also in conflict with our own lines of business which do the same thing? But, well, we aren't in conflict - this is a complementary part of our overall capabilities. > > - that clusters are hard. really, they aren't. they are not > > necessarily higher-maintenance, can be far more robust, usually > > do cost less. just about the only bad thing about clusters is > > that they tend to be somewhat larger in size. This is orthogonal to clusters. Or, well, we are even using CKRM today is some grid/cluster style applications. But that has no bearing on whether or not clusters is useful. > > - that partitioning actually makes sense. the appeal is that if > > you have a partition to yourself, you can only hurt yourself. > > but it also follows that burstiness in resource demand cannot be > > overlapped without either constantly tuning the partitions or > > infringing on the guarantee. Well, if you don't think it makes sense, don't buy one. And stay away from Xen, VMware, VirtualIron, PowerPC/pSeries hardware, Mainframes, Altix, IA64 platforms, Intel VT, AMD Pacifica, and, well, anyone else that is working to support virtualization, which is one key level of partitioning. I'm sorry but I'm not buying your argument here at all - it just has no relationship to what's going on at the user side as near as I can tell. > > CKRM is one of those things that could be done to Linux, and will benefit a > > few, but which will almost certainly hurt *most* of the community. > > > > let me say that the CKRM design is actually quite good. the issue is > > whether > > the extensive hooks it requires can be done (at all) in a way which does > > not disporportionately hurt maintainability or efficiency. Can you be more clear on how this will hurt *most* of the community? CKRM when not in use is not in any way intrusive. Can you take a look at the patch again and point out the "extensive" hooks for me? I've looked at "all" of them and I have trouble calling a couple of callbacks "extensive hooks". > > CKRM requires hooks into every resource-allocation decision fastpath: > > - if CKRM is not CONFIG, the only overhead is software maintenance. > > - if CKRM is CONFIG but not loaded, the overhead is a pointer check. > > - if CKRM is CONFIG and loaded, the overhead is a pointer check > > and a nontrivial callback. You left out a case here: CKRM is CONFIG and loaded and classes are defined. In all of the cases that you mentioned, if there are no
Re: 2.6.13-rc3-mm1 (ckrm)
Paul Jackson wrote: Martin wrote: No offense, but I really don't see why this matters at all ... the stuff in -mm is what's under consideration for merging - what's in SuSE is ... Yes - what's in SuSE doesn't matter, at least not directly. No - we are not just considering the CKRM that is in *-mm now, but also what can be expected to be proposed as part of CKRM in the future. If the CPU controller is not in *-mm now, but if one might reasonably expect it to be proposed as part of CKRM in the future, then we need to understand that. This is perhaps especially important in this case, where there is some reason to suspect that this additional piece is both non-trivial and essential to CKRM's purpose. The CKRM design explicitly considered this problem of some controllers being more unacceptable than the rest and part of the indirections introduced in CKRM are to allow the kernel community the flexibility of cherry-picking acceptable controllers. So if the current CPU controller implementation is considered too intrusive/unacceptable, it can be reworked or (and we certainly hope not) even rejected in perpetuity. Same for the other controllers as and when they're introduced and proposed for inclusion. -- Shailabh - 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.13-rc3-mm1 (ckrm)
Mark Hahn wrote: I suspect that the main problem is that this patch is not a mainstream kernel feature that will gain multiple uses, but rather provides support for a specific vendor middleware product used by that vendor and a few closely allied vendors. If it were smaller or less intrusive, such as a driver, this would not be a big problem. That's not the case. yes, that's the crux. CKRM is all about resolving conflicting resource demands in a multi-user, multi-server, multi-purpose machine. this is a huge undertaking, and I'd argue that it's completely inappropriate for *most* servers. that is, computers are generally so damn cheap that the clear trend is towards dedicating a machine to a specific purpose, rather than running eg, shell/MUA/MTA/FS/DB/etc all on a single machine. The argument about scale-up vs. scale-out is nowhere close to being resolved. To argue that any support for performance partitioning (which CKRM does) is in support of a lost cause is premature to say the least. this is *directly* in conflict with certain prominent products, such as the Altix and various less-prominent Linux-based mainframes. they're all about partitioning/virtualization - the big-iron aesthetic of splitting up a single machine. note that it's not just about "big", since cluster-based approaches can clearly scale far past big-iron, and are in effect statically partitioned. yes, buying a hideously expensive single box, and then chopping it into little pieces is more than a little bizarre, and is mainly based on a couple assumptions: - that clusters are hard. really, they aren't. they are not necessarily higher-maintenance, can be far more robust, usually do cost less. just about the only bad thing about clusters is that they tend to be somewhat larger in size. - that partitioning actually makes sense. the appeal is that if you have a partition to yourself, you can only hurt yourself. but it also follows that burstiness in resource demand cannot be overlapped without either constantly tuning the partitions or infringing on the guarantee. "constantly tuning the partitions" is effectively whats done by workload managers. But our earlier presentations and papers have made the case that this is not the only utility for performance isolation - simple needs like isolating one user from another on a general purpose server is also a need that cannot be met by any existing or proposed Linux kernel mechanisms today. If partitioning made so little sense and the case for clusters was that obvious, one would be hard put to explain why server consolidation is being actively pursued by so many firms, Solaris is bothering with coming up with Containers and Xen/VMWare getting all this attention. I don't think the concept of partitioning can be dismissed so easily. Of course, it must be noted that CKRM only provides performance isolation not fault isolation. But there is a need for that. Whether Linux chooses to let this need influence its design is another matter (which I hope we'll also discuss besides the implementation issues). CKRM is one of those things that could be done to Linux, and will benefit a few, but which will almost certainly hurt *most* of the community. let me say that the CKRM design is actually quite good. the issue is whether the extensive hooks it requires can be done (at all) in a way which does not disporportionately hurt maintainability or efficiency. If there are suggestions on implementing this better, it'll certainly be very welcome. CKRM requires hooks into every resource-allocation decision fastpath: - if CKRM is not CONFIG, the only overhead is software maintenance. - if CKRM is CONFIG but not loaded, the overhead is a pointer check. - if CKRM is CONFIG and loaded, the overhead is a pointer check and a nontrivial callback. but really, this is only for CKRM-enforced limits. CKRM really wants to change behavior in a more "weighted" way, not just causing an allocation/fork/packet to fail. a really meaningful CKRM needs to be tightly integrated into each resource manager - effecting each scheduler (process, memory, IO, net). I don't really see how full-on CKRM can be compiled out, unless these schedulers are made fully pluggable. This is a valid point for the CPU, memory and network controllers (I/O can be made pluggable quite easily). For the CPU controller in SuSE, the CKRM CPU controller can be turned on and off dynamically at runtime. Exploring a similar option for memory and network (incurring only a pointer check) could be explored. Keeping the overhead close to zero for kernel users not interested in CKRM is certainly one of our objectives. finally, I observe that pluggable, class-based resource _limits_ could probably be done without callbacks and potentially with low overhead. but mere limits doesn't meet CKRM's goal of flexible, wide-spread resource partitioning
Re: 2.6.13-rc3-mm1 (ckrm)
On Fri, 22 Jul 2005 13:46:37 +1000, Peter Williams wrote: > Gerrit Huizenga wrote: > >>I imagine that the cpu controller is missing from this version of CKRM > >>because the bugs introduced to the cpu controller during upgrading from > >>2.6.5 to 2.6.10 version have not yet been resolved. > > > > > > I don't know what bugs you are referring to here. I don't think we > > have any open defects with SuSE on the CPU scheduler in their releases. > > And that is not at all related to the reason for not having a CPU > > controller in the current patch set. > > The bugs were in the patches for the 2.6.10 kernel not SuSE's 2.6.5 > kernel. I reported some of them to the ckrm-tech mailing list at the > time. There were changes to the vanilla scheduler between 2.6.5 and > 2.6.10 that were not handled properly when the CKRM scheduler was > upgraded to the 2.6.10 kernel. Ah - okay - that makes sense. Those patches haven't gone through my review yet and I'm not directly tracking their status until I figure out what the right direction is with respect to a fair share style scheduler of some sort. I'm not convinced that the current one is something that is ready for mainline or is necessarily the right answer currently. But we do need to figure out something that will provide some level of CPU allocation minima & maxima for a class, where that solution will work well on a laptop or a huge server. Ideas in that space are welcome - I know of several proposed ideas in progress - the scheduler in SuSE and the forward port to 2.6.10 that you referred to; an idea for building a very simple interface on top of sched_domains for SMP systems (no fairness within a single CPU) and a proposal for timeslice manipulation that might provide some fairness that the Fujitsu folks are thinking about. There are probably others and honestly, I don't have any clue yet as to what the right long term/mainline direction should be here as yet. gerrit - 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.13-rc3-mm1 (ckrm)
Martin wrote: > No offense, but I really don't see why this matters at all ... the stuff > in -mm is what's under consideration for merging - what's in SuSE is ... Yes - what's in SuSE doesn't matter, at least not directly. No - we are not just considering the CKRM that is in *-mm now, but also what can be expected to be proposed as part of CKRM in the future. If the CPU controller is not in *-mm now, but if one might reasonably expect it to be proposed as part of CKRM in the future, then we need to understand that. This is perhaps especially important in this case, where there is some reason to suspect that this additional piece is both non-trivial and essential to CKRM's purpose. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401 - 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.13-rc3-mm1 (ckrm)
Gerrit Huizenga wrote: On Fri, 22 Jul 2005 11:06:14 +1000, Peter Williams wrote: Paul Jackson wrote: Matthew wrote: I don't see the large ifdefs you're referring to in -mm's kernel/sched.c. Perhaps someone who knows CKRM better than I can explain why the CKRM version in some SuSE releases based on 2.6.5 kernels has substantial code and some large ifdef's in sched.c, but the CKRM in *-mm doesn't. Or perhaps I'm confused. There's a good chance that this represents ongoing improvements that CKRM is making to reduce their footprint in core kernel code. Or perhaps there is a more sophisticated cpu controller in the SuSE kernel. As there is NO CKRM cpu controller in 2.6.13-rc3-mm1 (that I can see) the one in 2.6.5 is certainly more sophisticated :-). So the reason that the considerable mangling of sched.c evident in SuSE's 2.6.5 kernel source is not present is that the cpu controller is not included in these patches. Yeah - I don't really consider the current CPU controller code something ready for consideration yet for mainline merging. That doesn't mean we don't want a CPU controller for CKRM - just that what we have doesn't integrate cleanly/nicely with mainline. I imagine that the cpu controller is missing from this version of CKRM because the bugs introduced to the cpu controller during upgrading from 2.6.5 to 2.6.10 version have not yet been resolved. I don't know what bugs you are referring to here. I don't think we have any open defects with SuSE on the CPU scheduler in their releases. And that is not at all related to the reason for not having a CPU controller in the current patch set. The bugs were in the patches for the 2.6.10 kernel not SuSE's 2.6.5 kernel. I reported some of them to the ckrm-tech mailing list at the time. There were changes to the vanilla scheduler between 2.6.5 and 2.6.10 that were not handled properly when the CKRM scheduler was upgraded to the 2.6.10 kernel. Peter -- Peter Williams [EMAIL PROTECTED] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce - 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.13-rc3-mm1 (ckrm)
On Fri, 22 Jul 2005 11:06:14 +1000, Peter Williams wrote: > Paul Jackson wrote: > > Matthew wrote: > > > >>I don't see the large ifdefs you're referring to in -mm's > >>kernel/sched.c. > > > > > > Perhaps someone who knows CKRM better than I can explain why the CKRM > > version in some SuSE releases based on 2.6.5 kernels has substantial > > code and some large ifdef's in sched.c, but the CKRM in *-mm doesn't. > > Or perhaps I'm confused. There's a good chance that this represents > > ongoing improvements that CKRM is making to reduce their footprint > > in core kernel code. Or perhaps there is a more sophisticated cpu > > controller in the SuSE kernel. > > As there is NO CKRM cpu controller in 2.6.13-rc3-mm1 (that I can see) > the one in 2.6.5 is certainly more sophisticated :-). So the reason > that the considerable mangling of sched.c evident in SuSE's 2.6.5 kernel > source is not present is that the cpu controller is not included in > these patches. Yeah - I don't really consider the current CPU controller code something ready for consideration yet for mainline merging. That doesn't mean we don't want a CPU controller for CKRM - just that what we have doesn't integrate cleanly/nicely with mainline. > I imagine that the cpu controller is missing from this version of CKRM > because the bugs introduced to the cpu controller during upgrading from > 2.6.5 to 2.6.10 version have not yet been resolved. I don't know what bugs you are referring to here. I don't think we have any open defects with SuSE on the CPU scheduler in their releases. And that is not at all related to the reason for not having a CPU controller in the current patch set. gerrit - 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.13-rc3-mm1 (ckrm)
Paul Jackson wrote: Matthew wrote: I don't see the large ifdefs you're referring to in -mm's kernel/sched.c. Perhaps someone who knows CKRM better than I can explain why the CKRM version in some SuSE releases based on 2.6.5 kernels has substantial code and some large ifdef's in sched.c, but the CKRM in *-mm doesn't. Or perhaps I'm confused. There's a good chance that this represents ongoing improvements that CKRM is making to reduce their footprint in core kernel code. Or perhaps there is a more sophisticated cpu controller in the SuSE kernel. As there is NO CKRM cpu controller in 2.6.13-rc3-mm1 (that I can see) the one in 2.6.5 is certainly more sophisticated :-). So the reason that the considerable mangling of sched.c evident in SuSE's 2.6.5 kernel source is not present is that the cpu controller is not included in these patches. I imagine that the cpu controller is missing from this version of CKRM because the bugs introduced to the cpu controller during upgrading from 2.6.5 to 2.6.10 version have not yet been resolved. Peter -- Peter Williams [EMAIL PROTECTED] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce - 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.13-rc3-mm1 (ckrm)
Paul Jackson wrote: Matthew wrote: Perhaps someone who knows CKRM better than I can explain why the CKRM version in some SuSE releases based on 2.6.5 kernels has substantial code and some large ifdef's in sched.c, but the CKRM in *-mm doesn't. Or perhaps I'm confused. There's a good chance that this represents ongoing improvements that CKRM is making to reduce their footprint in core kernel code. Or perhaps there is a more sophisticated cpu controller in the SuSE kernel. No offense, but I really don't see why this matters at all ... the stuff in -mm is what's under consideration for merging - what's in SuSE is wholly irrelevant ? One obvious thing is that that codebase will be much older ... would be useful if people can direct critiques at the current codebase ;-) M. - 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.13-rc3-mm1 (ckrm)
Matthew wrote: > I don't see the large ifdefs you're referring to in -mm's > kernel/sched.c. Perhaps someone who knows CKRM better than I can explain why the CKRM version in some SuSE releases based on 2.6.5 kernels has substantial code and some large ifdef's in sched.c, but the CKRM in *-mm doesn't. Or perhaps I'm confused. There's a good chance that this represents ongoing improvements that CKRM is making to reduce their footprint in core kernel code. Or perhaps there is a more sophisticated cpu controller in the SuSE kernel. > Have you looked at more > recent benchmarks posted on CKRM-Tech around April 15th 2005? > ... > http://ckrm.sourceforge.net/downloads/ckrm-ols04-slides.pdf I had not seen these before. Thanks for the pointer. > The Rule-Based Classification Engine (RBCE) makes CKRM useful > without middleware. I'd be encouraged more if this went one step further, past pointing out that the API can be manipulated from the shell without requiring C code, to providing examples of who intends to _directly_ use this interface. The issue is perhaps less whether it's API is naturally C or shell code, or more of how many actual, independent, uses of this API are known to the community. A non-trivial API and mechanism that is de facto captive to a single middleware implementation (which may or may not apply here - I don't know) creates an additional review burden, because some of the natural forces that guide us to healthy long lasting interfaces are missing. If that concern applies here, it's certainly not insurmountable - but it should in my view raise the review barrier to acceptance. If other middleware or direct users are not essentially performing some of the review for us, we have to do it here with greater thoroughness. > If you could be more specific I'd be able to > respond in less general and abstract terms. Good come back . I made an effort along these lines last year, in the thread I referenced a few days ago: Classes: 1) what are they, 2) what is their name? http://sourceforge.net/mailarchive/forum.php?thread_id=5328162_id=35191 I doubt that it I have much more to contribute along these lines now. Sorry. > I haven't seen this limitation [128 cpus] ... Good - I presume that there is no longer, if there ever was, such a limitation. Thanks for you reply. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401 - 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.13-rc3-mm1 - breaks DRI
> >> > >> I also use 2.6.13-rc3-mm1. Will try with a previous version an report to > >> lkml if > >> it works. > >> > > > > I just tried 13-rc2-mm1 and dri is working again. Its reported to also work > > with 13-rc3. > Hmm no idea what could have broken it, I'm at OLS and don't have any DRI capable machine here yet.. so it'll be a while before I get to take a look at it .. I wouldn't be terribly surprised if some of the new mapping code might have some issues.. Dave. - 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.13-rc3-mm1 (ckrm)
On Sun, 2005-07-17 at 08:20 -0700, Paul Jackson wrote: > It is somewhat intrusive in the areas it controls, such as some large > ifdef's in kernel/sched.c. I don't see the large ifdefs you're referring to in -mm's kernel/sched.c. > The sched hooks may well impact the cost of maintaining the sched code, > which is always a hotbed of Linux kernel development. However others > who work in that area will have to speak to that concern. I don't see the hooks you're referring to in the -mm scheduler. > I tried just now to read through the ckrm hooks in fork, to see > what sort of impact they might have on scalability on large systems. > But I gave up after a couple layers of indirection. I saw several > atomic counters and a couple of spinlocks that I suspect (not at all > sure) lay on the fork main code path. I'd be surprised if this didn't > impact scalability. Earlier, according to my notes, I saw mention of > lmbench results in the OLS 2004 slides, indicating a several percent > cost of available cpu cycles. The OLS2004 slides are roughly 1 year old. Have you looked at more recent benchmarks posted on CKRM-Tech around April 15th 2005? They should be available in the CKRM-Tech archives on SourceForge at http://sourceforge.net/mailarchive/forum.php?thread_id=7025751_id=35191 (OLS 2004 Slide 24 of http://ckrm.sourceforge.net/downloads/ckrm-ols04-slides.pdf ) The OLS slide indicates that the overhead is generally less than 0.5usec compared to a total context switch time of anywhere from 2 to 5.5usec. There appears to be little difference in scalability since the overhead appears to oscillate around a constant. > vendor has a serious middleware software product that provides full > CKRM support. Acceptance of CKRM would be easier if multiple competing > middleware vendors were using it. It is also a concern that CKRM > is not really usable for its primary intended purpose except if it > is accompanied by this corresponding middleware, which I presume is The Rule-Based Classification Engine (RBCE) makes CKRM useful without middleware. It uses a table of rules to classify tasks. For example rules that would classify shells: echo 'path=/bin/bash,class=/rcfs/taskclass/shells' > /rcfs/ce/rules/classify_bash_shells echo 'path=/bin/tcsh,class=/rcfs/taskclass/shells' > /rcfs/ce/rules/classify_tcsh_shells .. And class shares would control the fork rate of those shells: echo 'res=numtasks,forkrate=1,forkrate_interval=1' > '/rcfs/taskclass/config' echo 'res=numtasks,guarantee=1000,limit=5000' > '/rcfs/taskclass/shells' No middleware necessary. > CKRM is in part a generalization and descendent of what I call fair > share schedulers. For example, the fork hooks for CKRM include a > forkrates controller, to slow down the rate of forking of tasks using > too much resources. > > No doubt the CKRM experts are already familiar with these, but for > the possible benefit of other readers: > > UNICOS Resource Administration - Chapter 4. Fair-share Scheduler > > http://oscinfo.osc.edu:8080/dynaweb/all/004-2302-001/@Generic__BookTextView/22883 > > SHARE II -- A User Administration and Resource Control System for UNIX > http://www.c-side.com/c/papers/lisa-91.html > > Solaris Resource Manager White Paper > http://wwws.sun.com/software/resourcemgr/wp-mixed/ > > ON THE PERFORMANCE IMPACT OF FAIR SHARE SCHEDULING > http://www.cs.umb.edu/~eb/goalmode/cmg2000final.htm > > A Fair Share Scheduler, J. Kay and P. Lauder > Communications of the ACM, January 1988, Volume 31, Number 1, pp 44-55. > > The documentation that I've noticed (likely I've missed something) > doesn't do an adequate job of making the case - providing the > motivation and context essential to understanding this patch set. The choice of algorithm is entirely up to the scheduler, memory allocator, etc. CKRM currently provides an interface for reading share values and does not impose any meaning on those shares -- that is the role of the scheduler. > Because CKRM provides an infrastructure for multiple controllers > (limiting forks, memory allocation and network rates) and multiple > classifiers and policies, its critical interfaces have rather > generic and abstract names. This makes it difficult for others to > approach CKRM, reducing the rate of peer review by other Linux kernel > developers, which is perhaps the key impediment to acceptance of CKRM. > If anything, CKRM tends to be a little too abstract. Generic and abstract names are appropriate for infrastructure that is not tied to hardware. If you could be more specific I'd be able to respond in less general and abstract terms. > My notes from many months ago indicate something about a 128 CPU > limit in CKRM. I don't know why, nor if it still applies. It is > certainly a smaller limit than the systems I care about. I haven't seen this limitation in the CKRM patches that went into -mm and I'd like to look into
Re: 2.6.13-rc3-mm1 - breaks DRI
On Thursday 21 July 2005 11:56, Andrew Morton wrote: > Ed Tomlinson <[EMAIL PROTECTED]> wrote: > > > >> -- Forwarded Message -- > >> > >> Subject: Re: Xorg and RADEON (dri disabled) > >> Date: Wednesday 20 July 2005 21:25 > >> From: Ed Tomlinson <[EMAIL PROTECTED]> > >> To: debian-amd64@lists.debian.org > >> Cc: Michal Schmidt <[EMAIL PROTECTED]> > >> > >> On Wednesday 20 July 2005 21:13, Michal Schmidt wrote: > >> > Ed Tomlinson wrote: > >> > > Hi, > >> > > > >> > > With Xorg I get: > >> > > > >> > > (==) RADEON(0): Write-combining range (0xd000,0x800) > >> > > drmOpenDevice: node name is /dev/dri/card0 > >> > > drmOpenDevice: open result is -1, (No such device) > >> > > drmOpenDevice: open result is -1, (No such device) > >> > > drmOpenDevice: Open failed > >> > > drmOpenDevice: node name is /dev/dri/card0 > >> > > drmOpenDevice: open result is -1, (No such device) > >> > > drmOpenDevice: open result is -1, (No such device) > >> > > drmOpenDevice: Open failed > >> > > drmOpenByBusid: Searching for BusID pci::01:00.0 > >> > > drmOpenDevice: node name is /dev/dri/card0 > >> > > drmOpenDevice: open result is 7, (OK) > >> > > drmOpenByBusid: drmOpenMinor returns 7 > >> > > drmOpenByBusid: drmGetBusid reports pci::01:00.0 > >> > > (II) RADEON(0): [drm] loaded kernel module for "radeon" driver > >> > > (II) RADEON(0): [drm] DRM interface version 1.2 > >> > > (II) RADEON(0): [drm] created "radeon" driver at busid > >> > > "pci::01:00.0" > >> > > (II) RADEON(0): [drm] added 8192 byte SAREA at 0xc2411000 > >> > > (II) RADEON(0): [drm] drmMap failed > >> > > (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI. > >> > > > >> > > And glxgears reports 300 frames per second. How do I get dri back? It > >> > > was working fine with XFree. The XF86Config-4 was changed by the > >> > > upgrade > >> > > dropping some parms in the Device section. Restoring them has no > >> > > effect > >> > > on the problem. > >> > >> > What kernel do you use? I get the same behaviour with 2.6.13-rc3-mm1, > >> > but it works with 2.6.13-rc3. > >> > >> I also use 2.6.13-rc3-mm1. Will try with a previous version an report to > >> lkml if > >> it works. > >> > > > > I just tried 13-rc2-mm1 and dri is working again. Its reported to also work > > with 13-rc3. > > Useful info, thanks. > > > What in mm1 is apt to be breaking dri? > > Faulty kernel programming ;) > > I assume that the failure to open /dev/dri/card0 only happens in rc3-mm1? The difference in the X logs is that the working one does not have the: (II) RADEON(0): [drm] created "radeon" driver at busid "pci::01:00.0" (II) RADEON(0): [drm] added 8192 byte SAREA at 0xc2411000 (II) RADEON(0): [drm] drmMap failed message. When it works it has has: (II) RADEON(0): [drm] created "radeon" driver at busid "pci::01:00.0" (II) RADEON(0): [drm] added 8192 byte SAREA at 0x10001000 (II) RADEON(0): [drm] mapped SAREA 0x10001000 to 0x2aaab2e67000 (II) RADEON(0): [drm] framebuffer handle = 0xd000 (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): [agp] Mode 0x1f004209 [AGP 0x10de/0x00e1; Card 0x1002/0x5961] (II) RADEON(0): [agp] 8192 kB allocated with handle 0x0001 (II) RADEON(0): [agp] ring handle = 0xe000 > Could you compare the dmesg output for 2.6.13-rc3 versus 2.6.13-rc3-mm1? > And double-check the .config settings: occasionally config options will be > renamed and `make oldconfig' causes things to get acidentally disabled. >From 13-rc2-mm1: Jul 21 07:31:20 grover kernel: [ 13.652465] Linux agpgart interface v0.101 (c) Dave Jones Jul 21 07:31:20 grover kernel: [ 13.652492] [drm] Initialized drm 1.0.0 20040925 and later Jul 21 07:31:34 grover kernel: [ 72.401795] [drm] Initialized radeon 1.16.0 20050311 on minor 0: ATI Technologies Inc RV280 [Radeon 9200] Jul 21 07:31:34 grover kernel: [ 72.402388] agpgart: Found an AGP 3.0 compliant device at :00:00.0. Jul 21 07:31:34 grover kernel: [ 72.402399] agpgart: Putting AGP V3 device at :00:00.0 into 4x mode Jul 21 07:31:34 grover kernel: [ 72.402419] agpgart: Putting AGP V3 device at :01:00.0 int
Re: 2.6.13-rc3-mm1 - breaks DRI
Ed Tomlinson <[EMAIL PROTECTED]> wrote: > >> -- Forwarded Message -- >> >> Subject: Re: Xorg and RADEON (dri disabled) >> Date: Wednesday 20 July 2005 21:25 >> From: Ed Tomlinson <[EMAIL PROTECTED]> >> To: debian-amd64@lists.debian.org >> Cc: Michal Schmidt <[EMAIL PROTECTED]> >> >> On Wednesday 20 July 2005 21:13, Michal Schmidt wrote: >> > Ed Tomlinson wrote: >> > > Hi, >> > > >> > > With Xorg I get: >> > > >> > > (==) RADEON(0): Write-combining range (0xd000,0x800) >> > > drmOpenDevice: node name is /dev/dri/card0 >> > > drmOpenDevice: open result is -1, (No such device) >> > > drmOpenDevice: open result is -1, (No such device) >> > > drmOpenDevice: Open failed >> > > drmOpenDevice: node name is /dev/dri/card0 >> > > drmOpenDevice: open result is -1, (No such device) >> > > drmOpenDevice: open result is -1, (No such device) >> > > drmOpenDevice: Open failed >> > > drmOpenByBusid: Searching for BusID pci::01:00.0 >> > > drmOpenDevice: node name is /dev/dri/card0 >> > > drmOpenDevice: open result is 7, (OK) >> > > drmOpenByBusid: drmOpenMinor returns 7 >> > > drmOpenByBusid: drmGetBusid reports pci::01:00.0 >> > > (II) RADEON(0): [drm] loaded kernel module for "radeon" driver >> > > (II) RADEON(0): [drm] DRM interface version 1.2 >> > > (II) RADEON(0): [drm] created "radeon" driver at busid "pci::01:00.0" >> > > (II) RADEON(0): [drm] added 8192 byte SAREA at 0xc2411000 >> > > (II) RADEON(0): [drm] drmMap failed >> > > (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI. >> > > >> > > And glxgears reports 300 frames per second. How do I get dri back? It >> > > was working fine with XFree. The XF86Config-4 was changed by the upgrade >> > > dropping some parms in the Device section. Restoring them has no effect >> > > on the problem. >> >> > What kernel do you use? I get the same behaviour with 2.6.13-rc3-mm1, >> > but it works with 2.6.13-rc3. >> >> I also use 2.6.13-rc3-mm1. Will try with a previous version an report to >> lkml if >> it works. >> > > I just tried 13-rc2-mm1 and dri is working again. Its reported to also work > with 13-rc3. Useful info, thanks. > What in mm1 is apt to be breaking dri? Faulty kernel programming ;) I assume that the failure to open /dev/dri/card0 only happens in rc3-mm1? Could you compare the dmesg output for 2.6.13-rc3 versus 2.6.13-rc3-mm1? And double-check the .config settings: occasionally config options will be renamed and `make oldconfig' causes things to get acidentally disabled. - 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.13-rc3-mm1 - breaks DRI
Hi, I just tried 13-rc2-mm1 and dri is working again. Its reported to also work with 13-rc3. What in mm1 is apt to be breaking dri? Thanks Ed Tomlinson -- Forwarded Message -- Subject: Re: Xorg and RADEON (dri disabled) Date: Wednesday 20 July 2005 21:25 From: Ed Tomlinson <[EMAIL PROTECTED]> To: debian-amd64@lists.debian.org Cc: Michal Schmidt <[EMAIL PROTECTED]> On Wednesday 20 July 2005 21:13, Michal Schmidt wrote: > Ed Tomlinson wrote: > > Hi, > > > > With Xorg I get: > > > > (==) RADEON(0): Write-combining range (0xd000,0x800) > > drmOpenDevice: node name is /dev/dri/card0 > > drmOpenDevice: open result is -1, (No such device) > > drmOpenDevice: open result is -1, (No such device) > > drmOpenDevice: Open failed > > drmOpenDevice: node name is /dev/dri/card0 > > drmOpenDevice: open result is -1, (No such device) > > drmOpenDevice: open result is -1, (No such device) > > drmOpenDevice: Open failed > > drmOpenByBusid: Searching for BusID pci::01:00.0 > > drmOpenDevice: node name is /dev/dri/card0 > > drmOpenDevice: open result is 7, (OK) > > drmOpenByBusid: drmOpenMinor returns 7 > > drmOpenByBusid: drmGetBusid reports pci::01:00.0 > > (II) RADEON(0): [drm] loaded kernel module for "radeon" driver > > (II) RADEON(0): [drm] DRM interface version 1.2 > > (II) RADEON(0): [drm] created "radeon" driver at busid "pci::01:00.0" > > (II) RADEON(0): [drm] added 8192 byte SAREA at 0xc2411000 > > (II) RADEON(0): [drm] drmMap failed > > (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI. > > > > And glxgears reports 300 frames per second. How do I get dri back? It > > was working fine with XFree. The XF86Config-4 was changed by the upgrade > > dropping some parms in the Device section. Restoring them has no effect > > on the problem. > What kernel do you use? I get the same behaviour with 2.6.13-rc3-mm1, > but it works with 2.6.13-rc3. I also use 2.6.13-rc3-mm1. Will try with a previous version an report to lkml if it works. Thanks Ed --- - 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.13-rc3-mm1 - breaks DRI
Hi, I just tried 13-rc2-mm1 and dri is working again. Its reported to also work with 13-rc3. What in mm1 is apt to be breaking dri? Thanks Ed Tomlinson -- Forwarded Message -- Subject: Re: Xorg and RADEON (dri disabled) Date: Wednesday 20 July 2005 21:25 From: Ed Tomlinson [EMAIL PROTECTED] To: debian-amd64@lists.debian.org Cc: Michal Schmidt [EMAIL PROTECTED] On Wednesday 20 July 2005 21:13, Michal Schmidt wrote: Ed Tomlinson wrote: Hi, With Xorg I get: (==) RADEON(0): Write-combining range (0xd000,0x800) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: Searching for BusID pci::01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: drmOpenMinor returns 7 drmOpenByBusid: drmGetBusid reports pci::01:00.0 (II) RADEON(0): [drm] loaded kernel module for radeon driver (II) RADEON(0): [drm] DRM interface version 1.2 (II) RADEON(0): [drm] created radeon driver at busid pci::01:00.0 (II) RADEON(0): [drm] added 8192 byte SAREA at 0xc2411000 (II) RADEON(0): [drm] drmMap failed (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI. And glxgears reports 300 frames per second. How do I get dri back? It was working fine with XFree. The XF86Config-4 was changed by the upgrade dropping some parms in the Device section. Restoring them has no effect on the problem. What kernel do you use? I get the same behaviour with 2.6.13-rc3-mm1, but it works with 2.6.13-rc3. I also use 2.6.13-rc3-mm1. Will try with a previous version an report to lkml if it works. Thanks Ed --- - 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.13-rc3-mm1 - breaks DRI
Ed Tomlinson [EMAIL PROTECTED] wrote: -- Forwarded Message -- Subject: Re: Xorg and RADEON (dri disabled) Date: Wednesday 20 July 2005 21:25 From: Ed Tomlinson [EMAIL PROTECTED] To: debian-amd64@lists.debian.org Cc: Michal Schmidt [EMAIL PROTECTED] On Wednesday 20 July 2005 21:13, Michal Schmidt wrote: Ed Tomlinson wrote: Hi, With Xorg I get: (==) RADEON(0): Write-combining range (0xd000,0x800) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: Searching for BusID pci::01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: drmOpenMinor returns 7 drmOpenByBusid: drmGetBusid reports pci::01:00.0 (II) RADEON(0): [drm] loaded kernel module for radeon driver (II) RADEON(0): [drm] DRM interface version 1.2 (II) RADEON(0): [drm] created radeon driver at busid pci::01:00.0 (II) RADEON(0): [drm] added 8192 byte SAREA at 0xc2411000 (II) RADEON(0): [drm] drmMap failed (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI. And glxgears reports 300 frames per second. How do I get dri back? It was working fine with XFree. The XF86Config-4 was changed by the upgrade dropping some parms in the Device section. Restoring them has no effect on the problem. What kernel do you use? I get the same behaviour with 2.6.13-rc3-mm1, but it works with 2.6.13-rc3. I also use 2.6.13-rc3-mm1. Will try with a previous version an report to lkml if it works. I just tried 13-rc2-mm1 and dri is working again. Its reported to also work with 13-rc3. Useful info, thanks. What in mm1 is apt to be breaking dri? Faulty kernel programming ;) I assume that the failure to open /dev/dri/card0 only happens in rc3-mm1? Could you compare the dmesg output for 2.6.13-rc3 versus 2.6.13-rc3-mm1? And double-check the .config settings: occasionally config options will be renamed and `make oldconfig' causes things to get acidentally disabled. - 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.13-rc3-mm1 - breaks DRI
On Thursday 21 July 2005 11:56, Andrew Morton wrote: Ed Tomlinson [EMAIL PROTECTED] wrote: -- Forwarded Message -- Subject: Re: Xorg and RADEON (dri disabled) Date: Wednesday 20 July 2005 21:25 From: Ed Tomlinson [EMAIL PROTECTED] To: debian-amd64@lists.debian.org Cc: Michal Schmidt [EMAIL PROTECTED] On Wednesday 20 July 2005 21:13, Michal Schmidt wrote: Ed Tomlinson wrote: Hi, With Xorg I get: (==) RADEON(0): Write-combining range (0xd000,0x800) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: Searching for BusID pci::01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: drmOpenMinor returns 7 drmOpenByBusid: drmGetBusid reports pci::01:00.0 (II) RADEON(0): [drm] loaded kernel module for radeon driver (II) RADEON(0): [drm] DRM interface version 1.2 (II) RADEON(0): [drm] created radeon driver at busid pci::01:00.0 (II) RADEON(0): [drm] added 8192 byte SAREA at 0xc2411000 (II) RADEON(0): [drm] drmMap failed (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI. And glxgears reports 300 frames per second. How do I get dri back? It was working fine with XFree. The XF86Config-4 was changed by the upgrade dropping some parms in the Device section. Restoring them has no effect on the problem. What kernel do you use? I get the same behaviour with 2.6.13-rc3-mm1, but it works with 2.6.13-rc3. I also use 2.6.13-rc3-mm1. Will try with a previous version an report to lkml if it works. I just tried 13-rc2-mm1 and dri is working again. Its reported to also work with 13-rc3. Useful info, thanks. What in mm1 is apt to be breaking dri? Faulty kernel programming ;) I assume that the failure to open /dev/dri/card0 only happens in rc3-mm1? The difference in the X logs is that the working one does not have the: (II) RADEON(0): [drm] created radeon driver at busid pci::01:00.0 (II) RADEON(0): [drm] added 8192 byte SAREA at 0xc2411000 (II) RADEON(0): [drm] drmMap failed message. When it works it has has: (II) RADEON(0): [drm] created radeon driver at busid pci::01:00.0 (II) RADEON(0): [drm] added 8192 byte SAREA at 0x10001000 (II) RADEON(0): [drm] mapped SAREA 0x10001000 to 0x2aaab2e67000 (II) RADEON(0): [drm] framebuffer handle = 0xd000 (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): [agp] Mode 0x1f004209 [AGP 0x10de/0x00e1; Card 0x1002/0x5961] (II) RADEON(0): [agp] 8192 kB allocated with handle 0x0001 (II) RADEON(0): [agp] ring handle = 0xe000 Could you compare the dmesg output for 2.6.13-rc3 versus 2.6.13-rc3-mm1? And double-check the .config settings: occasionally config options will be renamed and `make oldconfig' causes things to get acidentally disabled. From 13-rc2-mm1: Jul 21 07:31:20 grover kernel: [ 13.652465] Linux agpgart interface v0.101 (c) Dave Jones Jul 21 07:31:20 grover kernel: [ 13.652492] [drm] Initialized drm 1.0.0 20040925 and later Jul 21 07:31:34 grover kernel: [ 72.401795] [drm] Initialized radeon 1.16.0 20050311 on minor 0: ATI Technologies Inc RV280 [Radeon 9200] Jul 21 07:31:34 grover kernel: [ 72.402388] agpgart: Found an AGP 3.0 compliant device at :00:00.0. Jul 21 07:31:34 grover kernel: [ 72.402399] agpgart: Putting AGP V3 device at :00:00.0 into 4x mode Jul 21 07:31:34 grover kernel: [ 72.402419] agpgart: Putting AGP V3 device at :01:00.0 into 4x mode Jul 21 07:31:35 grover kernel: [ 72.421888] [drm] Loading R200 Microcode From 13-rc3-mm1: Jul 20 18:59:34 grover kernel: [ 13.837537] Linux agpgart interface v0.101 (c) Dave Jones Jul 20 18:59:34 grover kernel: [ 13.837565] [drm] Initialized drm 1.0.0 20040925 and later Jul 20 18:59:48 grover kernel: [ 71.638470] [drm] Initialized radeon 1.16.0 20050311 on minor 0: ATI Techno logies Inc RV280 [Radeon 9200] Both .configs are fine. Kernels have agp compiled in with DRM modular. CONFIG_GART_IOMMU=y CONFIG_AGP=y CONFIG_AGP_AMD64=y # CONFIG_AGP_INTEL is not set CONFIG_DRM=y CONFIG_DRM_TDFX=m CONFIG_DRM_R128=m CONFIG_DRM_RADEON=m Hope this helps (Its an AMD64 Kernel), Ed - 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.13-rc3-mm1 (ckrm)
On Sun, 2005-07-17 at 08:20 -0700, Paul Jackson wrote: snip It is somewhat intrusive in the areas it controls, such as some large ifdef's in kernel/sched.c. I don't see the large ifdefs you're referring to in -mm's kernel/sched.c. The sched hooks may well impact the cost of maintaining the sched code, which is always a hotbed of Linux kernel development. However others who work in that area will have to speak to that concern. I don't see the hooks you're referring to in the -mm scheduler. I tried just now to read through the ckrm hooks in fork, to see what sort of impact they might have on scalability on large systems. But I gave up after a couple layers of indirection. I saw several atomic counters and a couple of spinlocks that I suspect (not at all sure) lay on the fork main code path. I'd be surprised if this didn't impact scalability. Earlier, according to my notes, I saw mention of lmbench results in the OLS 2004 slides, indicating a several percent cost of available cpu cycles. The OLS2004 slides are roughly 1 year old. Have you looked at more recent benchmarks posted on CKRM-Tech around April 15th 2005? They should be available in the CKRM-Tech archives on SourceForge at http://sourceforge.net/mailarchive/forum.php?thread_id=7025751forum_id=35191 (OLS 2004 Slide 24 of http://ckrm.sourceforge.net/downloads/ckrm-ols04-slides.pdf ) The OLS slide indicates that the overhead is generally less than 0.5usec compared to a total context switch time of anywhere from 2 to 5.5usec. There appears to be little difference in scalability since the overhead appears to oscillate around a constant. snip vendor has a serious middleware software product that provides full CKRM support. Acceptance of CKRM would be easier if multiple competing middleware vendors were using it. It is also a concern that CKRM is not really usable for its primary intended purpose except if it is accompanied by this corresponding middleware, which I presume is The Rule-Based Classification Engine (RBCE) makes CKRM useful without middleware. It uses a table of rules to classify tasks. For example rules that would classify shells: echo 'path=/bin/bash,class=/rcfs/taskclass/shells' /rcfs/ce/rules/classify_bash_shells echo 'path=/bin/tcsh,class=/rcfs/taskclass/shells' /rcfs/ce/rules/classify_tcsh_shells .. And class shares would control the fork rate of those shells: echo 'res=numtasks,forkrate=1,forkrate_interval=1' '/rcfs/taskclass/config' echo 'res=numtasks,guarantee=1000,limit=5000' '/rcfs/taskclass/shells' No middleware necessary. snip CKRM is in part a generalization and descendent of what I call fair share schedulers. For example, the fork hooks for CKRM include a forkrates controller, to slow down the rate of forking of tasks using too much resources. No doubt the CKRM experts are already familiar with these, but for the possible benefit of other readers: UNICOS Resource Administration - Chapter 4. Fair-share Scheduler http://oscinfo.osc.edu:8080/dynaweb/all/004-2302-001/@Generic__BookTextView/22883 SHARE II -- A User Administration and Resource Control System for UNIX http://www.c-side.com/c/papers/lisa-91.html Solaris Resource Manager White Paper http://wwws.sun.com/software/resourcemgr/wp-mixed/ ON THE PERFORMANCE IMPACT OF FAIR SHARE SCHEDULING http://www.cs.umb.edu/~eb/goalmode/cmg2000final.htm A Fair Share Scheduler, J. Kay and P. Lauder Communications of the ACM, January 1988, Volume 31, Number 1, pp 44-55. The documentation that I've noticed (likely I've missed something) doesn't do an adequate job of making the case - providing the motivation and context essential to understanding this patch set. The choice of algorithm is entirely up to the scheduler, memory allocator, etc. CKRM currently provides an interface for reading share values and does not impose any meaning on those shares -- that is the role of the scheduler. Because CKRM provides an infrastructure for multiple controllers (limiting forks, memory allocation and network rates) and multiple classifiers and policies, its critical interfaces have rather generic and abstract names. This makes it difficult for others to approach CKRM, reducing the rate of peer review by other Linux kernel developers, which is perhaps the key impediment to acceptance of CKRM. If anything, CKRM tends to be a little too abstract. Generic and abstract names are appropriate for infrastructure that is not tied to hardware. If you could be more specific I'd be able to respond in less general and abstract terms. snip My notes from many months ago indicate something about a 128 CPU limit in CKRM. I don't know why, nor if it still applies. It is certainly a smaller limit than the systems I care about. I haven't seen this limitation in the CKRM patches that went into -mm and I'd like to look into this. Where did you see this limit?
Re: 2.6.13-rc3-mm1 - breaks DRI
I also use 2.6.13-rc3-mm1. Will try with a previous version an report to lkml if it works. I just tried 13-rc2-mm1 and dri is working again. Its reported to also work with 13-rc3. Hmm no idea what could have broken it, I'm at OLS and don't have any DRI capable machine here yet.. so it'll be a while before I get to take a look at it .. I wouldn't be terribly surprised if some of the new mapping code might have some issues.. Dave. - 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.13-rc3-mm1 (ckrm)
Matthew wrote: I don't see the large ifdefs you're referring to in -mm's kernel/sched.c. Perhaps someone who knows CKRM better than I can explain why the CKRM version in some SuSE releases based on 2.6.5 kernels has substantial code and some large ifdef's in sched.c, but the CKRM in *-mm doesn't. Or perhaps I'm confused. There's a good chance that this represents ongoing improvements that CKRM is making to reduce their footprint in core kernel code. Or perhaps there is a more sophisticated cpu controller in the SuSE kernel. Have you looked at more recent benchmarks posted on CKRM-Tech around April 15th 2005? ... http://ckrm.sourceforge.net/downloads/ckrm-ols04-slides.pdf I had not seen these before. Thanks for the pointer. The Rule-Based Classification Engine (RBCE) makes CKRM useful without middleware. I'd be encouraged more if this went one step further, past pointing out that the API can be manipulated from the shell without requiring C code, to providing examples of who intends to _directly_ use this interface. The issue is perhaps less whether it's API is naturally C or shell code, or more of how many actual, independent, uses of this API are known to the community. A non-trivial API and mechanism that is de facto captive to a single middleware implementation (which may or may not apply here - I don't know) creates an additional review burden, because some of the natural forces that guide us to healthy long lasting interfaces are missing. If that concern applies here, it's certainly not insurmountable - but it should in my view raise the review barrier to acceptance. If other middleware or direct users are not essentially performing some of the review for us, we have to do it here with greater thoroughness. If you could be more specific I'd be able to respond in less general and abstract terms. Good come back grin. I made an effort along these lines last year, in the thread I referenced a few days ago: Classes: 1) what are they, 2) what is their name? http://sourceforge.net/mailarchive/forum.php?thread_id=5328162forum_id=35191 I doubt that it I have much more to contribute along these lines now. Sorry. I haven't seen this limitation [128 cpus] ... Good - I presume that there is no longer, if there ever was, such a limitation. Thanks for you reply. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson [EMAIL PROTECTED] 1.925.600.0401 - 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.13-rc3-mm1 (ckrm)
Paul Jackson wrote: Matthew wrote: Perhaps someone who knows CKRM better than I can explain why the CKRM version in some SuSE releases based on 2.6.5 kernels has substantial code and some large ifdef's in sched.c, but the CKRM in *-mm doesn't. Or perhaps I'm confused. There's a good chance that this represents ongoing improvements that CKRM is making to reduce their footprint in core kernel code. Or perhaps there is a more sophisticated cpu controller in the SuSE kernel. No offense, but I really don't see why this matters at all ... the stuff in -mm is what's under consideration for merging - what's in SuSE is wholly irrelevant ? One obvious thing is that that codebase will be much older ... would be useful if people can direct critiques at the current codebase ;-) M. - 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.13-rc3-mm1 (ckrm)
Paul Jackson wrote: Matthew wrote: I don't see the large ifdefs you're referring to in -mm's kernel/sched.c. Perhaps someone who knows CKRM better than I can explain why the CKRM version in some SuSE releases based on 2.6.5 kernels has substantial code and some large ifdef's in sched.c, but the CKRM in *-mm doesn't. Or perhaps I'm confused. There's a good chance that this represents ongoing improvements that CKRM is making to reduce their footprint in core kernel code. Or perhaps there is a more sophisticated cpu controller in the SuSE kernel. As there is NO CKRM cpu controller in 2.6.13-rc3-mm1 (that I can see) the one in 2.6.5 is certainly more sophisticated :-). So the reason that the considerable mangling of sched.c evident in SuSE's 2.6.5 kernel source is not present is that the cpu controller is not included in these patches. I imagine that the cpu controller is missing from this version of CKRM because the bugs introduced to the cpu controller during upgrading from 2.6.5 to 2.6.10 version have not yet been resolved. Peter -- Peter Williams [EMAIL PROTECTED] Learning, n. The kind of ignorance distinguishing the studious. -- Ambrose Bierce - 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.13-rc3-mm1 (ckrm)
On Fri, 22 Jul 2005 11:06:14 +1000, Peter Williams wrote: Paul Jackson wrote: Matthew wrote: I don't see the large ifdefs you're referring to in -mm's kernel/sched.c. Perhaps someone who knows CKRM better than I can explain why the CKRM version in some SuSE releases based on 2.6.5 kernels has substantial code and some large ifdef's in sched.c, but the CKRM in *-mm doesn't. Or perhaps I'm confused. There's a good chance that this represents ongoing improvements that CKRM is making to reduce their footprint in core kernel code. Or perhaps there is a more sophisticated cpu controller in the SuSE kernel. As there is NO CKRM cpu controller in 2.6.13-rc3-mm1 (that I can see) the one in 2.6.5 is certainly more sophisticated :-). So the reason that the considerable mangling of sched.c evident in SuSE's 2.6.5 kernel source is not present is that the cpu controller is not included in these patches. Yeah - I don't really consider the current CPU controller code something ready for consideration yet for mainline merging. That doesn't mean we don't want a CPU controller for CKRM - just that what we have doesn't integrate cleanly/nicely with mainline. I imagine that the cpu controller is missing from this version of CKRM because the bugs introduced to the cpu controller during upgrading from 2.6.5 to 2.6.10 version have not yet been resolved. I don't know what bugs you are referring to here. I don't think we have any open defects with SuSE on the CPU scheduler in their releases. And that is not at all related to the reason for not having a CPU controller in the current patch set. gerrit - 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.13-rc3-mm1 (ckrm)
Gerrit Huizenga wrote: On Fri, 22 Jul 2005 11:06:14 +1000, Peter Williams wrote: Paul Jackson wrote: Matthew wrote: I don't see the large ifdefs you're referring to in -mm's kernel/sched.c. Perhaps someone who knows CKRM better than I can explain why the CKRM version in some SuSE releases based on 2.6.5 kernels has substantial code and some large ifdef's in sched.c, but the CKRM in *-mm doesn't. Or perhaps I'm confused. There's a good chance that this represents ongoing improvements that CKRM is making to reduce their footprint in core kernel code. Or perhaps there is a more sophisticated cpu controller in the SuSE kernel. As there is NO CKRM cpu controller in 2.6.13-rc3-mm1 (that I can see) the one in 2.6.5 is certainly more sophisticated :-). So the reason that the considerable mangling of sched.c evident in SuSE's 2.6.5 kernel source is not present is that the cpu controller is not included in these patches. Yeah - I don't really consider the current CPU controller code something ready for consideration yet for mainline merging. That doesn't mean we don't want a CPU controller for CKRM - just that what we have doesn't integrate cleanly/nicely with mainline. I imagine that the cpu controller is missing from this version of CKRM because the bugs introduced to the cpu controller during upgrading from 2.6.5 to 2.6.10 version have not yet been resolved. I don't know what bugs you are referring to here. I don't think we have any open defects with SuSE on the CPU scheduler in their releases. And that is not at all related to the reason for not having a CPU controller in the current patch set. The bugs were in the patches for the 2.6.10 kernel not SuSE's 2.6.5 kernel. I reported some of them to the ckrm-tech mailing list at the time. There were changes to the vanilla scheduler between 2.6.5 and 2.6.10 that were not handled properly when the CKRM scheduler was upgraded to the 2.6.10 kernel. Peter -- Peter Williams [EMAIL PROTECTED] Learning, n. The kind of ignorance distinguishing the studious. -- Ambrose Bierce - 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.13-rc3-mm1 (ckrm)
Martin wrote: No offense, but I really don't see why this matters at all ... the stuff in -mm is what's under consideration for merging - what's in SuSE is ... Yes - what's in SuSE doesn't matter, at least not directly. No - we are not just considering the CKRM that is in *-mm now, but also what can be expected to be proposed as part of CKRM in the future. If the CPU controller is not in *-mm now, but if one might reasonably expect it to be proposed as part of CKRM in the future, then we need to understand that. This is perhaps especially important in this case, where there is some reason to suspect that this additional piece is both non-trivial and essential to CKRM's purpose. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson [EMAIL PROTECTED] 1.925.600.0401 - 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.13-rc3-mm1 (ckrm)
On Fri, 22 Jul 2005 13:46:37 +1000, Peter Williams wrote: Gerrit Huizenga wrote: I imagine that the cpu controller is missing from this version of CKRM because the bugs introduced to the cpu controller during upgrading from 2.6.5 to 2.6.10 version have not yet been resolved. I don't know what bugs you are referring to here. I don't think we have any open defects with SuSE on the CPU scheduler in their releases. And that is not at all related to the reason for not having a CPU controller in the current patch set. The bugs were in the patches for the 2.6.10 kernel not SuSE's 2.6.5 kernel. I reported some of them to the ckrm-tech mailing list at the time. There were changes to the vanilla scheduler between 2.6.5 and 2.6.10 that were not handled properly when the CKRM scheduler was upgraded to the 2.6.10 kernel. Ah - okay - that makes sense. Those patches haven't gone through my review yet and I'm not directly tracking their status until I figure out what the right direction is with respect to a fair share style scheduler of some sort. I'm not convinced that the current one is something that is ready for mainline or is necessarily the right answer currently. But we do need to figure out something that will provide some level of CPU allocation minima maxima for a class, where that solution will work well on a laptop or a huge server. Ideas in that space are welcome - I know of several proposed ideas in progress - the scheduler in SuSE and the forward port to 2.6.10 that you referred to; an idea for building a very simple interface on top of sched_domains for SMP systems (no fairness within a single CPU) and a proposal for timeslice manipulation that might provide some fairness that the Fujitsu folks are thinking about. There are probably others and honestly, I don't have any clue yet as to what the right long term/mainline direction should be here as yet. gerrit - 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.13-rc3-mm1 (ckrm)
Mark Hahn wrote: I suspect that the main problem is that this patch is not a mainstream kernel feature that will gain multiple uses, but rather provides support for a specific vendor middleware product used by that vendor and a few closely allied vendors. If it were smaller or less intrusive, such as a driver, this would not be a big problem. That's not the case. yes, that's the crux. CKRM is all about resolving conflicting resource demands in a multi-user, multi-server, multi-purpose machine. this is a huge undertaking, and I'd argue that it's completely inappropriate for *most* servers. that is, computers are generally so damn cheap that the clear trend is towards dedicating a machine to a specific purpose, rather than running eg, shell/MUA/MTA/FS/DB/etc all on a single machine. The argument about scale-up vs. scale-out is nowhere close to being resolved. To argue that any support for performance partitioning (which CKRM does) is in support of a lost cause is premature to say the least. this is *directly* in conflict with certain prominent products, such as the Altix and various less-prominent Linux-based mainframes. they're all about partitioning/virtualization - the big-iron aesthetic of splitting up a single machine. note that it's not just about big, since cluster-based approaches can clearly scale far past big-iron, and are in effect statically partitioned. yes, buying a hideously expensive single box, and then chopping it into little pieces is more than a little bizarre, and is mainly based on a couple assumptions: - that clusters are hard. really, they aren't. they are not necessarily higher-maintenance, can be far more robust, usually do cost less. just about the only bad thing about clusters is that they tend to be somewhat larger in size. - that partitioning actually makes sense. the appeal is that if you have a partition to yourself, you can only hurt yourself. but it also follows that burstiness in resource demand cannot be overlapped without either constantly tuning the partitions or infringing on the guarantee. constantly tuning the partitions is effectively whats done by workload managers. But our earlier presentations and papers have made the case that this is not the only utility for performance isolation - simple needs like isolating one user from another on a general purpose server is also a need that cannot be met by any existing or proposed Linux kernel mechanisms today. If partitioning made so little sense and the case for clusters was that obvious, one would be hard put to explain why server consolidation is being actively pursued by so many firms, Solaris is bothering with coming up with Containers and Xen/VMWare getting all this attention. I don't think the concept of partitioning can be dismissed so easily. Of course, it must be noted that CKRM only provides performance isolation not fault isolation. But there is a need for that. Whether Linux chooses to let this need influence its design is another matter (which I hope we'll also discuss besides the implementation issues). CKRM is one of those things that could be done to Linux, and will benefit a few, but which will almost certainly hurt *most* of the community. let me say that the CKRM design is actually quite good. the issue is whether the extensive hooks it requires can be done (at all) in a way which does not disporportionately hurt maintainability or efficiency. If there are suggestions on implementing this better, it'll certainly be very welcome. CKRM requires hooks into every resource-allocation decision fastpath: - if CKRM is not CONFIG, the only overhead is software maintenance. - if CKRM is CONFIG but not loaded, the overhead is a pointer check. - if CKRM is CONFIG and loaded, the overhead is a pointer check and a nontrivial callback. but really, this is only for CKRM-enforced limits. CKRM really wants to change behavior in a more weighted way, not just causing an allocation/fork/packet to fail. a really meaningful CKRM needs to be tightly integrated into each resource manager - effecting each scheduler (process, memory, IO, net). I don't really see how full-on CKRM can be compiled out, unless these schedulers are made fully pluggable. This is a valid point for the CPU, memory and network controllers (I/O can be made pluggable quite easily). For the CPU controller in SuSE, the CKRM CPU controller can be turned on and off dynamically at runtime. Exploring a similar option for memory and network (incurring only a pointer check) could be explored. Keeping the overhead close to zero for kernel users not interested in CKRM is certainly one of our objectives. finally, I observe that pluggable, class-based resource _limits_ could probably be done without callbacks and potentially with low overhead. but mere limits doesn't meet CKRM's goal of flexible, wide-spread resource partitioning within a
Re: 2.6.13-rc3-mm1 (ckrm)
Paul Jackson wrote: Martin wrote: No offense, but I really don't see why this matters at all ... the stuff in -mm is what's under consideration for merging - what's in SuSE is ... Yes - what's in SuSE doesn't matter, at least not directly. No - we are not just considering the CKRM that is in *-mm now, but also what can be expected to be proposed as part of CKRM in the future. If the CPU controller is not in *-mm now, but if one might reasonably expect it to be proposed as part of CKRM in the future, then we need to understand that. This is perhaps especially important in this case, where there is some reason to suspect that this additional piece is both non-trivial and essential to CKRM's purpose. The CKRM design explicitly considered this problem of some controllers being more unacceptable than the rest and part of the indirections introduced in CKRM are to allow the kernel community the flexibility of cherry-picking acceptable controllers. So if the current CPU controller implementation is considered too intrusive/unacceptable, it can be reworked or (and we certainly hope not) even rejected in perpetuity. Same for the other controllers as and when they're introduced and proposed for inclusion. -- Shailabh - 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.13-rc3-mm1 (ckrm)
Sorry - I didn't see Mark's original comment, so I'm replying to a reply which I did get. ;-) On Thu, 21 Jul 2005 23:59:09 EDT, Shailabh Nagar wrote: Mark Hahn wrote: I suspect that the main problem is that this patch is not a mainstream kernel feature that will gain multiple uses, but rather provides support for a specific vendor middleware product used by that vendor and a few closely allied vendors. If it were smaller or less intrusive, such as a driver, this would not be a big problem. That's not the case. yes, that's the crux. CKRM is all about resolving conflicting resource demands in a multi-user, multi-server, multi-purpose machine. this is a huge undertaking, and I'd argue that it's completely inappropriate for *most* servers. that is, computers are generally so damn cheap that the clear trend is towards dedicating a machine to a specific purpose, rather than running eg, shell/MUA/MTA/FS/DB/etc all on a single machine. This is a big NAK - if computers are so damn cheap, why is virtualization and consolidation such a big deal? Well, the answer is actually that floor space, heat, and power are also continuing to be very important in the overall equation. And, buying machines which are dedicated but often 80-99% idle occasionally bothers people who are concerned about wasting planetary resources for no good reason. Yeah, we can stamp out thousands of metal boxes, but if just a couple can do the same work, well, let's consolidate. Less wasted metal, less wasted heat, less wasted power, less air conditioning, wow, we are now part of the eco-computing movement! ;-) this is *directly* in conflict with certain prominent products, such as the Altix and various less-prominent Linux-based mainframes. they're all about partitioning/virtualization - the big-iron aesthetic of splitting up a single machine. note that it's not just about big, since cluster-based approaches can clearly scale far past big-iron, and are in effect statically partitioned. yes, buying a hideously expensive single box, and then chopping it into little pieces is more than a little bizarre, and is mainly based on a couple assumptions: Well, yeah IBM has been doing this virtualization partitioning stuff for ages at lots of different levels for lots of reasons. If we are in such direct conflict with Altix, aren't we also in conflict with our own lines of business which do the same thing? But, well, we aren't in conflict - this is a complementary part of our overall capabilities. - that clusters are hard. really, they aren't. they are not necessarily higher-maintenance, can be far more robust, usually do cost less. just about the only bad thing about clusters is that they tend to be somewhat larger in size. This is orthogonal to clusters. Or, well, we are even using CKRM today is some grid/cluster style applications. But that has no bearing on whether or not clusters is useful. - that partitioning actually makes sense. the appeal is that if you have a partition to yourself, you can only hurt yourself. but it also follows that burstiness in resource demand cannot be overlapped without either constantly tuning the partitions or infringing on the guarantee. Well, if you don't think it makes sense, don't buy one. And stay away from Xen, VMware, VirtualIron, PowerPC/pSeries hardware, Mainframes, Altix, IA64 platforms, Intel VT, AMD Pacifica, and, well, anyone else that is working to support virtualization, which is one key level of partitioning. I'm sorry but I'm not buying your argument here at all - it just has no relationship to what's going on at the user side as near as I can tell. CKRM is one of those things that could be done to Linux, and will benefit a few, but which will almost certainly hurt *most* of the community. let me say that the CKRM design is actually quite good. the issue is whether the extensive hooks it requires can be done (at all) in a way which does not disporportionately hurt maintainability or efficiency. Can you be more clear on how this will hurt *most* of the community? CKRM when not in use is not in any way intrusive. Can you take a look at the patch again and point out the extensive hooks for me? I've looked at all of them and I have trouble calling a couple of callbacks extensive hooks. CKRM requires hooks into every resource-allocation decision fastpath: - if CKRM is not CONFIG, the only overhead is software maintenance. - if CKRM is CONFIG but not loaded, the overhead is a pointer check. - if CKRM is CONFIG and loaded, the overhead is a pointer check and a nontrivial callback. You left out a case here: CKRM is CONFIG and loaded and classes are defined. In all of the cases that you mentioned, if there are no classes defined, the overhead is still unmeasurable for any real workload. Refer to the archives
Re: 2.6.13-rc3-mm1 (ckrm)
yes, that's the crux. CKRM is all about resolving conflicting resource demands in a multi-user, multi-server, multi-purpose machine. this is a huge undertaking, and I'd argue that it's completely inappropriate for *most* servers. that is, computers are generally so damn cheap that the clear trend is towards dedicating a machine to a specific purpose, rather than running eg, shell/MUA/MTA/FS/DB/etc all on a single machine. This is a big NAK - if computers are so damn cheap, why is virtualization and consolidation such a big deal? Well, the answer is actually that yes, you did miss my point. I'm actually arguing that it's bad design to attempt to arbitrate within a single shared user-space. you make the fast path slower and less maintainable. if you are really concerned about isolating many competing servers on a single piece of hardware, then run separate virtualized environments, each with its own user-space. - 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.13-rc3-mm1 (ckrm)
On Fri, 22 Jul 2005 00:53:58 EDT, Mark Hahn wrote: yes, that's the crux. CKRM is all about resolving conflicting resource demands in a multi-user, multi-server, multi-purpose machine. this is a huge undertaking, and I'd argue that it's completely inappropriate for *most* servers. that is, computers are generally so damn cheap that the clear trend is towards dedicating a machine to a specific purpose, rather than running eg, shell/MUA/MTA/FS/DB/etc all on a single machine. This is a big NAK - if computers are so damn cheap, why is virtualization and consolidation such a big deal? Well, the answer is actually that yes, you did miss my point. I'm actually arguing that it's bad design to attempt to arbitrate within a single shared user-space. you make the fast path slower and less maintainable. if you are really concerned about isolating many competing servers on a single piece of hardware, then run separate virtualized environments, each with its own user-space. I'm willing to agree to disagree. I'm in favor of full virtualization as well, as it is appropriate to certain styles of workloads. I also have enough end users who also want to share user level, share tasks, yet also have some level of balancing between the resource consumption of the various environments. I don't think you are one of those end users, though. I don't think I'm required to make everyone happy all the time. ;) BTW, does your mailer purposefully remove cc:'s? Seems like that is normally considered impolite. gerrit - 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.13-rc3-mm1 (ckrm)
of the various environments. I don't think you are one of those end users, though. I don't think I'm required to make everyone happy all the time. ;) the issue is whether CKRM (in it's real form, not this thin edge) will noticably hurt Linux's fast-path. - 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.13-rc3-mm1 (ckrm)
Well said, Mark. Thanks. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401 - 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.13-rc3-mm1 (ckrm)
Well said, Mark. Thanks. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson [EMAIL PROTECTED] 1.925.600.0401 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.13-rc3-mm1] v9fs: Replace v9fs_block_bits() with fls()
Replace v9fs_block_bits() with fls()
Originally from Rene Scharfe.
Signed-off-by: Eric Van Hensbergen <[EMAIL PROTECTED]>
---
commit f2a177d5cc8ba35ac8473961def629890d30a2f7
tree d81534c54698cb502bf7810488b03be36f36a528
parent 76ebbc7869a06014e638ad72148c375cf6644655
author Eric Van Hensbergen <[EMAIL PROTECTED]> Tue, 19 Jul 2005 09:29:15 -0500
committer Eric Van Hensbergen <[EMAIL PROTECTED]> Tue, 19 Jul 2005 09:29:15
-0500
fs/9p/vfs_super.c | 33 +++--
1 files changed, 3 insertions(+), 30 deletions(-)
diff --git a/fs/9p/vfs_super.c b/fs/9p/vfs_super.c
--- a/fs/9p/vfs_super.c
+++ b/fs/9p/vfs_super.c
@@ -25,6 +25,7 @@
*
*/
+#include
#include
#include
#include
@@ -74,34 +75,6 @@ static int v9fs_set_super(struct super_b
}
/**
- * v9fs_block_bits - Determine bits in blocksize (from NFS Code)
- * @bsize: blocksize
- * @nrbitsp: number of bits
- *
- * this bit from linux/fs/nfs/inode.c
- * Copyright (C) 1992 Rick Sladkey
- * XXX - shouldn't there be a global linux function for this?
- *
- */
-
-static inline unsigned long
-v9fs_block_bits(unsigned long bsize, unsigned char *nrbitsp)
-{
- /* make sure blocksize is a power of two */
- if ((bsize & (bsize - 1)) || nrbitsp) {
- unsigned char nrbits;
-
- for (nrbits = 31; nrbits && !(bsize & (1 << nrbits));
-nrbits--) ;
- bsize = 1 << nrbits;
- if (nrbitsp)
- *nrbitsp = nrbits;
- }
-
- return bsize;
-}
-
-/**
* v9fs_fill_super - populate superblock with info
* @sb: superblock
* @v9ses: session information
@@ -113,8 +86,8 @@ v9fs_fill_super(struct super_block *sb,
int flags)
{
sb->s_maxbytes = MAX_LFS_FILESIZE;
- sb->s_blocksize =
- v9fs_block_bits(v9ses->maxdata, >s_blocksize_bits);
+ sb->s_blocksize_bits = fls(v9ses->maxdata - 1);
+ sb->s_blocksize = 1 << sb->s_blocksize_bits;
sb->s_magic = V9FS_MAGIC;
sb->s_op = _super_ops;
-
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.13-rc3-mm1
On 7/15/05, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > Changes since 2.6.13-rc2-mm2: > > > git-drm.patch > git-audit.patch > git-input.patch > git-kbuild.patch make help br0ken, missing matching `'' for binrpm-pkg. -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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.13-rc3-mm1
On 7/15/05, Andrew Morton [EMAIL PROTECTED] wrote: Changes since 2.6.13-rc2-mm2: git-drm.patch git-audit.patch git-input.patch git-kbuild.patch make help br0ken, missing matching `'' for binrpm-pkg. -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.13-rc3-mm1] v9fs: Replace v9fs_block_bits() with fls()
Replace v9fs_block_bits() with fls()
Originally from Rene Scharfe.
Signed-off-by: Eric Van Hensbergen [EMAIL PROTECTED]
---
commit f2a177d5cc8ba35ac8473961def629890d30a2f7
tree d81534c54698cb502bf7810488b03be36f36a528
parent 76ebbc7869a06014e638ad72148c375cf6644655
author Eric Van Hensbergen [EMAIL PROTECTED] Tue, 19 Jul 2005 09:29:15 -0500
committer Eric Van Hensbergen [EMAIL PROTECTED] Tue, 19 Jul 2005 09:29:15
-0500
fs/9p/vfs_super.c | 33 +++--
1 files changed, 3 insertions(+), 30 deletions(-)
diff --git a/fs/9p/vfs_super.c b/fs/9p/vfs_super.c
--- a/fs/9p/vfs_super.c
+++ b/fs/9p/vfs_super.c
@@ -25,6 +25,7 @@
*
*/
+#include linux/kernel.h
#include linux/config.h
#include linux/module.h
#include linux/errno.h
@@ -74,34 +75,6 @@ static int v9fs_set_super(struct super_b
}
/**
- * v9fs_block_bits - Determine bits in blocksize (from NFS Code)
- * @bsize: blocksize
- * @nrbitsp: number of bits
- *
- * this bit from linux/fs/nfs/inode.c
- * Copyright (C) 1992 Rick Sladkey
- * XXX - shouldn't there be a global linux function for this?
- *
- */
-
-static inline unsigned long
-v9fs_block_bits(unsigned long bsize, unsigned char *nrbitsp)
-{
- /* make sure blocksize is a power of two */
- if ((bsize (bsize - 1)) || nrbitsp) {
- unsigned char nrbits;
-
- for (nrbits = 31; nrbits !(bsize (1 nrbits));
-nrbits--) ;
- bsize = 1 nrbits;
- if (nrbitsp)
- *nrbitsp = nrbits;
- }
-
- return bsize;
-}
-
-/**
* v9fs_fill_super - populate superblock with info
* @sb: superblock
* @v9ses: session information
@@ -113,8 +86,8 @@ v9fs_fill_super(struct super_block *sb,
int flags)
{
sb-s_maxbytes = MAX_LFS_FILESIZE;
- sb-s_blocksize =
- v9fs_block_bits(v9ses-maxdata, sb-s_blocksize_bits);
+ sb-s_blocksize_bits = fls(v9ses-maxdata - 1);
+ sb-s_blocksize = 1 sb-s_blocksize_bits;
sb-s_magic = V9FS_MAGIC;
sb-s_op = v9fs_super_ops;
-
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.13-rc3-mm1
On Sat, Jul 16, 2005 at 09:32:49PM -0400, wrote: > On Fri, Jul 15, 2005 at 01:36:53AM -0700, Andrew Morton wrote: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/ > > > +suspend-update-documentation.patch > > +swsusp-fix-printks-and-cleanups.patch > > +swsusp-fix-remaining-u32-vs-pm_message_t-confusion.patch > > +swsusp-switch-pm_message_t-to-struct.patch > > +swsusp-switch-pm_message_t-to-struct-pmac_zilog-fix.patch > > +swsusp-switch-pm_message_t-to-struct-ppc32-fixes.patch > > +fix-pm_message_t-stuff-in-mm-tree-netdev.patch > I needed this little patch too. It's boot-tested; I have a MESH controller. Thanks! - diff -aurN linux-2.6.13-rc3-mm1/drivers/scsi/mesh.c linux-2.6.13-rc3-mm1_changed/drivers/scsi/mesh.c --- linux-2.6.13-rc3-mm1/drivers/scsi/mesh.c2005-07-16 01:46:44.0 -0400 +++ linux-2.6.13-rc3-mm1_changed/drivers/scsi/mesh.c2005-07-18 07:52:04.0 -0400 @@ -1766,7 +1766,7 @@ struct mesh_state *ms = (struct mesh_state *)macio_get_drvdata(mdev); unsigned long flags; - if (state == mdev->ofdev.dev.power.power_state || state < 2) + if (state.event == mdev->ofdev.dev.power.power_state.event || state.event < 2) return 0; scsi_block_requests(ms->host); @@ -1781,7 +1781,7 @@ disable_irq(ms->meshintr); set_mesh_power(ms, 0); - mdev->ofdev.dev.power.power_state = state; + mdev->ofdev.dev.power.power_state.event = state.event; return 0; } @@ -1791,7 +1791,7 @@ struct mesh_state *ms = (struct mesh_state *)macio_get_drvdata(mdev); unsigned long flags; - if (mdev->ofdev.dev.power.power_state == 0) + if (mdev->ofdev.dev.power.power_state.event == 0) return 0; set_mesh_power(ms, 1); @@ -1802,7 +1802,7 @@ enable_irq(ms->meshintr); scsi_unblock_requests(ms->host); - mdev->ofdev.dev.power.power_state = 0; + mdev->ofdev.dev.power.power_state.event = 0; return 0; } -- Joseph Fannin [EMAIL PROTECTED] "That's all I have to say about that." -- Forrest Gump. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.13-rc3-mm1] connector: fix missing dependencies in Kconfig
Hello Andrew, This patch fixes missing dependencies in drivers/connector/Kconfig file. We have to ensure that the dependencies of the selected variable are fulfilled otherwise it can produce some undefined references during the kernel compilation. This problem was reported by Adrian Bunk. Signed-off-by: [EMAIL PROTECTED] Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- Index: linux-2.6.13-rc3-mm1/drivers/connector/Kconfig === --- linux-2.6.13-rc3-mm1.orig/drivers/connector/Kconfig 2005-07-18 13:35:26.0 +0200 +++ linux-2.6.13-rc3-mm1/drivers/connector/Kconfig 2005-07-18 13:37:43.0 +0200 @@ -12,6 +12,7 @@ config CONNECTOR config EXIT_CONNECTOR bool "Enable exit connector" + depends on NET select CONNECTOR default y ---help--- @@ -23,6 +24,7 @@ config EXIT_CONNECTOR config FORK_CONNECTOR bool "Enable fork connector" + depends on NET select CONNECTOR default y ---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.13-rc3-mm1
Hi! > I'm getting this (on ppc32, though I don't think it matters): > > CC drivers/video/chipsfb.o > drivers/video/chipsfb.c: In function `chipsfb_pci_suspend': > drivers/video/chipsfb.c:465: error: invalid operands to binary == > drivers/video/chipsfb.c:467: error: invalid operands to binary != > make[3]: *** [drivers/video/chipsfb.o] Error 1 > make[2]: *** [drivers/video] Error 2 > make[1]: *** [drivers] Error 2 > make[1]: Leaving directory > `/usr/src/linux-ctesiphon/linux-2.6.13-rc3-mm1' > make: *** [stamp-build] Error 2 > > The above-quoted patches seem to be the culprit, but my feeble > attempts at making a patch didn't work out. Should be easy. Just add .event at right places... > But I can't help but notice that every linux-suspend HOWTO tells > you to patch in swsusp2 as a first step -- the consensus seems to be > that it you want clean and conservative code, use swsusp1; if you want > suspending to *work*, use swsusp2. How many people are actually able > to make use of swsusp1? Is anyone testing it besides Mr. Machek? SuSE ships it in production, so I believe we have at least as many users as suspend2... Pavel -- teflon -- maybe it is a trademark, but it should not be. - 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.13-rc3-mm1 (ckrm)
Hi, > > What, in your opinion, makes it "obviously unmergeable"? Controlling resource assignment, I think that concept is good. But the design is another matter that it seems somewhat overkilled with the current CKRM. > I suspect that the main problem is that this patch is not a mainstream > kernel feature that will gain multiple uses, but rather provides > support for a specific vendor middleware product used by that > vendor and a few closely allied vendors. If it were smaller or > less intrusive, such as a driver, this would not be a big problem. > That's not the case. I believe this feature would also make desktop users happier -- controlling X-server, mpeg player, video capturing and all that -- if the code becomes much simpler and easier to use. > A major restructuring of this patch set could be considered, This > might involve making the metric tools (that monitor memory, fork > and network usage rates per task) separate patches useful for other > purposes. It might also make the rate limiters in fork, alloc and > network i/o separately useful patches. I mean here genuinely useful > and understandable in their own right, independent of some abstract > CKRM framework. That makes sense. > Though hints have been dropped, I have not seen any public effort to > integrate CKRM with either cpusets or scheduler domains or process > accounting. By this I don't mean recoding cpusets using the CKRM > infrastructure; that proposal received _extensive_ consideration > earlier, and I am as certain as ever that it made no sense. Rather I > could imagine the CKRM folks extending cpusets to manage resources > on a per-cpuset basis, not just on a per-task or task class basis. > Similarly, it might make sense to use CKRM to manage resources on > a per-sched domain basis, and to integrate the resource tracking > of CKRM with the resource tracking needs of system accounting. >From a standpoint of the users, CKRM and CPUSETS should be managed seamlessly through the same interface though I'm not sure whether your idea is the best yet. Thanks, Hirokazu Takahashi. - 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.13-rc3-mm1 (ckrm)
Hi, What, in your opinion, makes it obviously unmergeable? Controlling resource assignment, I think that concept is good. But the design is another matter that it seems somewhat overkilled with the current CKRM. I suspect that the main problem is that this patch is not a mainstream kernel feature that will gain multiple uses, but rather provides support for a specific vendor middleware product used by that vendor and a few closely allied vendors. If it were smaller or less intrusive, such as a driver, this would not be a big problem. That's not the case. I believe this feature would also make desktop users happier -- controlling X-server, mpeg player, video capturing and all that -- if the code becomes much simpler and easier to use. A major restructuring of this patch set could be considered, This might involve making the metric tools (that monitor memory, fork and network usage rates per task) separate patches useful for other purposes. It might also make the rate limiters in fork, alloc and network i/o separately useful patches. I mean here genuinely useful and understandable in their own right, independent of some abstract CKRM framework. That makes sense. Though hints have been dropped, I have not seen any public effort to integrate CKRM with either cpusets or scheduler domains or process accounting. By this I don't mean recoding cpusets using the CKRM infrastructure; that proposal received _extensive_ consideration earlier, and I am as certain as ever that it made no sense. Rather I could imagine the CKRM folks extending cpusets to manage resources on a per-cpuset basis, not just on a per-task or task class basis. Similarly, it might make sense to use CKRM to manage resources on a per-sched domain basis, and to integrate the resource tracking of CKRM with the resource tracking needs of system accounting. From a standpoint of the users, CKRM and CPUSETS should be managed seamlessly through the same interface though I'm not sure whether your idea is the best yet. Thanks, Hirokazu Takahashi. - 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.13-rc3-mm1
Hi! I'm getting this (on ppc32, though I don't think it matters): CC drivers/video/chipsfb.o drivers/video/chipsfb.c: In function `chipsfb_pci_suspend': drivers/video/chipsfb.c:465: error: invalid operands to binary == drivers/video/chipsfb.c:467: error: invalid operands to binary != make[3]: *** [drivers/video/chipsfb.o] Error 1 make[2]: *** [drivers/video] Error 2 make[1]: *** [drivers] Error 2 make[1]: Leaving directory `/usr/src/linux-ctesiphon/linux-2.6.13-rc3-mm1' make: *** [stamp-build] Error 2 The above-quoted patches seem to be the culprit, but my feeble attempts at making a patch didn't work out. Should be easy. Just add .event at right places... But I can't help but notice that every linux-suspend HOWTO tells you to patch in swsusp2 as a first step -- the consensus seems to be that it you want clean and conservative code, use swsusp1; if you want suspending to *work*, use swsusp2. How many people are actually able to make use of swsusp1? Is anyone testing it besides Mr. Machek? SuSE ships it in production, so I believe we have at least as many users as suspend2... Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.13-rc3-mm1] connector: fix missing dependencies in Kconfig
Hello Andrew, This patch fixes missing dependencies in drivers/connector/Kconfig file. We have to ensure that the dependencies of the selected variable are fulfilled otherwise it can produce some undefined references during the kernel compilation. This problem was reported by Adrian Bunk. Signed-off-by: [EMAIL PROTECTED] Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- Index: linux-2.6.13-rc3-mm1/drivers/connector/Kconfig === --- linux-2.6.13-rc3-mm1.orig/drivers/connector/Kconfig 2005-07-18 13:35:26.0 +0200 +++ linux-2.6.13-rc3-mm1/drivers/connector/Kconfig 2005-07-18 13:37:43.0 +0200 @@ -12,6 +12,7 @@ config CONNECTOR config EXIT_CONNECTOR bool Enable exit connector + depends on NET select CONNECTOR default y ---help--- @@ -23,6 +24,7 @@ config EXIT_CONNECTOR config FORK_CONNECTOR bool Enable fork connector + depends on NET select CONNECTOR default y ---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.13-rc3-mm1
On Sat, Jul 16, 2005 at 09:32:49PM -0400, wrote: On Fri, Jul 15, 2005 at 01:36:53AM -0700, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/ +suspend-update-documentation.patch +swsusp-fix-printks-and-cleanups.patch +swsusp-fix-remaining-u32-vs-pm_message_t-confusion.patch +swsusp-switch-pm_message_t-to-struct.patch +swsusp-switch-pm_message_t-to-struct-pmac_zilog-fix.patch +swsusp-switch-pm_message_t-to-struct-ppc32-fixes.patch +fix-pm_message_t-stuff-in-mm-tree-netdev.patch I needed this little patch too. It's boot-tested; I have a MESH controller. Thanks! - diff -aurN linux-2.6.13-rc3-mm1/drivers/scsi/mesh.c linux-2.6.13-rc3-mm1_changed/drivers/scsi/mesh.c --- linux-2.6.13-rc3-mm1/drivers/scsi/mesh.c2005-07-16 01:46:44.0 -0400 +++ linux-2.6.13-rc3-mm1_changed/drivers/scsi/mesh.c2005-07-18 07:52:04.0 -0400 @@ -1766,7 +1766,7 @@ struct mesh_state *ms = (struct mesh_state *)macio_get_drvdata(mdev); unsigned long flags; - if (state == mdev-ofdev.dev.power.power_state || state 2) + if (state.event == mdev-ofdev.dev.power.power_state.event || state.event 2) return 0; scsi_block_requests(ms-host); @@ -1781,7 +1781,7 @@ disable_irq(ms-meshintr); set_mesh_power(ms, 0); - mdev-ofdev.dev.power.power_state = state; + mdev-ofdev.dev.power.power_state.event = state.event; return 0; } @@ -1791,7 +1791,7 @@ struct mesh_state *ms = (struct mesh_state *)macio_get_drvdata(mdev); unsigned long flags; - if (mdev-ofdev.dev.power.power_state == 0) + if (mdev-ofdev.dev.power.power_state.event == 0) return 0; set_mesh_power(ms, 1); @@ -1802,7 +1802,7 @@ enable_irq(ms-meshintr); scsi_unblock_requests(ms-host); - mdev-ofdev.dev.power.power_state = 0; + mdev-ofdev.dev.power.power_state.event = 0; return 0; } -- Joseph Fannin [EMAIL PROTECTED] That's all I have to say about that. -- Forrest Gump. - 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.13-rc3-mm1: mount problems w/ 3ware on dual Opteron
On Friday, 15 of July 2005 10:36, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/ > > (http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.13-rc3-mm1.gz until > kernel.org syncs up) Apparently, mount does not work with partitions located on a 3ware RAID (8006-2PL controller) in a dual-Opteron box (64-bit kernel). If the kernel is configured with preemption and NUMA, it cannot mount any "real" filesystems and the output of "mount" is the following: rootfs on / type ext3 (rw) /dev/root on / type ext3 (rw) proc on /proc type proc (rw,nodiratime) sysfs on /sys type sysfs (rw) tmpfs on /dev/shm type tmpfs (rw) (hand-copied from the screen). I have tried some other combinations (ie. preemption w/o NUMA, NUMA w/o preemption etc.) and it seems that it works better with CONFIG_PREEMPT_NONE set, although even it this case some filesystems are mounted read-only. The mainline kernels (ie. -rc3 and -rc3-git[1-4]) have no such problems. Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" - 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.13-rc3-mm1: a regression
On Saturday, 16 of July 2005 23:39, Andrew Morton wrote: > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > > > > On Friday, 15 of July 2005 10:36, Andrew Morton wrote: > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/ > > > > > > (http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.13-rc3-mm1.gz until > > > kernel.org syncs up) > > > > There seems to be a regression wrt 2.6.13-rc3 which causes my box (Asus > > L5D, > > Athlon 64 + nForce3) to hang solid during resume from disk on battery > > power. > > > > First, 2.6.13-rc3-mm1 is affected by the problems described at: > > http://bugzilla.kernel.org/show_bug.cgi?id=4416 > > http://bugzilla.kernel.org/show_bug.cgi?id=4665 > > These problems go away after applying the two attached patches. Then, the > > box resumes on AC power but hangs solid during resume on battery power. > > The problem is 100% reproducible and I think it's related to ACPI. > > That recent acpi merge seems to have damaged a number of people... > > Are you able to test Linus's latest -git spanshot? See if there's a > difference between -linus and -mm behaviour? I was afraid you would say so. ;-) The -rc3-git-[2-4] kernels are unaffected by the problem described, so it seems to be specific to -rc3-mm1. Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" - 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/
