Re: Linux 4.19-rc4 released, an apology, and a maintainership note
Re: Linux 4.19-rc4 released, an apology, and a maintainership note
Re: Linux 4.19-rc4 released, an apology, and a maintainership note
Hi Linus. I was "around linux-kernel" some 10 years ago and still to this date sometimes check e.g. lkml.org where I happened upon this; felt it hard to resist commenting on one specific bit... Whereas you concentrate on net-positive effect on code quality of an at times "crass" communication style, I believe there is or used to be an actually larger net-positive on community: the very fact that you as project leader feel/felt free to sometimes tell people off is and is I believe widely taken to be a sign that the Linux project leader still considers himself part of the community; is anti-hierarchical in that sense, and as such a large positive for a community a significant majority of which would not have (had) it any other way. Now, Linux has of course long outgrown its hacker-beginnings; I would expect that by now an overwhelming majority of developers is part of a corporate hierarchy anyway and therefore not themselves free to respond to you "on equal terms" even if they were personally inclined to do so. The above may hence be somewhat obsolete in reality -- and I'm also sure that this is for you more personal than for someone like me reading it on LKML(.org), but hearing you describe your style up to now as _wrong_ still feels quite, well, wrong. At the very least historically it wasn't, and it if is more now it at the very least still reflects quite positively on honesty and openness. Rene.
Re: Linux 4.19-rc4 released, an apology, and a maintainership note
Hi Linus. I was "around linux-kernel" some 10 years ago and still to this date sometimes check e.g. lkml.org where I happened upon this; felt it hard to resist commenting on one specific bit... Whereas you concentrate on net-positive effect on code quality of an at times "crass" communication style, I believe there is or used to be an actually larger net-positive on community: the very fact that you as project leader feel/felt free to sometimes tell people off is and is I believe widely taken to be a sign that the Linux project leader still considers himself part of the community; is anti-hierarchical in that sense, and as such a large positive for a community a significant majority of which would not have (had) it any other way. Now, Linux has of course long outgrown its hacker-beginnings; I would expect that by now an overwhelming majority of developers is part of a corporate hierarchy anyway and therefore not themselves free to respond to you "on equal terms" even if they were personally inclined to do so. The above may hence be somewhat obsolete in reality -- and I'm also sure that this is for you more personal than for someone like me reading it on LKML(.org), but hearing you describe your style up to now as _wrong_ still feels quite, well, wrong. At the very least historically it wasn't, and it if is more now it at the very least still reflects quite positively on honesty and openness. Rene.
Re: Patch kernel: I have 8 Gbytes RAM, but why I can only allocate 2.8 Gbytes RAM for a single process?
On 25-02-08 08:44, Ady Wicaksono wrote: I have 8 Gbytes RAM, but why I can allocate 2.8 Gbytes RAM for a single process? How to patch kernel so I have more than 2.8 Gbytes limitation? [ ... ] flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl est cid xtpr Run a 64-bit kernel and userspace. not a 32-bit. Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch kernel: I have 8 Gbytes RAM, but why I can only allocate 2.8 Gbytes RAM for a single process?
On 25-02-08 08:44, Ady Wicaksono wrote: I have 8 Gbytes RAM, but why I can allocate 2.8 Gbytes RAM for a single process? How to patch kernel so I have more than 2.8 Gbytes limitation? [ ... ] flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl est cid xtpr Run a 64-bit kernel and userspace. not a 32-bit. Rene. -- 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: Question about your git habits
On 23-02-08 01:37, Chase Venters wrote: Or perhaps you create a temporary topical branch for each thing you are working on, and commit arbitrary changes then checkout another branch when you need to change gears, finally --squashing the intermediate commits when a particular piece of work is done? No very specific advice to give but this is what I do and then pull all (compilable) topic branches into a "local" branch for complation. Just wanted to remark that a definite downside is that switching branches a lot also touches the tree a lot and hence tends to trigger quite unwelcome amounts of recompiles. Using ccache would proably be effective in this situation but I keep neglecting to check it out... Rene -- 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: Question about your git habits
On 23-02-08 01:37, Chase Venters wrote: Or perhaps you create a temporary topical branch for each thing you are working on, and commit arbitrary changes then checkout another branch when you need to change gears, finally --squashing the intermediate commits when a particular piece of work is done? No very specific advice to give but this is what I do and then pull all (compilable) topic branches into a local branch for complation. Just wanted to remark that a definite downside is that switching branches a lot also touches the tree a lot and hence tends to trigger quite unwelcome amounts of recompiles. Using ccache would proably be effective in this situation but I keep neglecting to check it out... Rene -- 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: pnp_bus_resume(): inconsequent NULL checking
On 21-02-08 16:26, Bjorn Helgaas wrote: I'll push it upstream, but a coverity warning seems like a marginal excuse for putting it in 2.6.25. Is there any real reason it can't wait until 2.6.26? No, but we're only at -rc2. Dumb little things such as this needn't wait an entire development cycle I'd feel but I obviously don't feel strongly about the issue itself. Rene. -- 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: pnp_bus_resume(): inconsequent NULL checking
On 21-02-08 16:26, Bjorn Helgaas wrote: I'll push it upstream, but a coverity warning seems like a marginal excuse for putting it in 2.6.25. Is there any real reason it can't wait until 2.6.26? No, but we're only at -rc2. Dumb little things such as this needn't wait an entire development cycle I'd feel but I obviously don't feel strongly about the issue itself. Rene. -- 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: [linux-kernel] Re: [PATCH] x86: use explicit timing delay for pit accesses in kernel and pcspkr driver
On 20-02-08 21:13, David P. Reed wrote:
Actually, disparaging things as "one idiotic system" doesn't seem like a
long-term thoughtful process - it's not even accurate.
Whatever we think about systems using port 0x80, fact of the matter is that
they do and outside of legacy stuff that isn't applicable to these systems,
Linux needs to stop using it (post ACPI init at least) to be able to run on
them.
As options of doing so we have:
1) Replace the port 0x80 I/O delay with nothing. Determined to be unsafe.
2) Replace 0x80 with another port. None are really available and DMI based
switching gets to be unmaintainable and has a such been shot down.
3) Replace the port 0x80 I/O delay with a udelay(2). Should work well enough
in practice for the remaining users outside legacy drivers after (Alan's)
cleaning up.
The remaining (possible) problem is that pre calibration microseconds are a
total fiction and at least PIT init happens before calibration. In practice
I believe this might not be much of a real-world problem since for whatever
initial value for loops_per_jiffy we get at least our old double short jump
that is enough of a delay for 386 and 486 but I sympathise with anone, such
as HPA, who'd consider my beliefs not a particular guarantee.
So, we need a more useful pre calibration udelay. Ugly as it might be,
through something like the attached. Alan, could you perhaps comment?
With the problam surfacing only post ACPI init, the _last_ remaining option
is talking to the PIT using port 0x80 at init and using udelay after but I
myself will not be submitting a patch to do so. Insane mess.
It would be good to get this crap sorted relatively quickly so we can do
away with the io_delay mongering even pre .26 again. It introduces boot
parameters and as such becomes part of API somewhat, so if it's not going to
stay let's kill it quickly.
Ren
commit 9c679215248e837b34242632d5a22adf9a247021
Author: Rene Herman <[EMAIL PROTECTED]>
Date: Wed Feb 20 12:52:30 2008 +0100
x86: per CPU family loops_per_jiffy initialization
Following the current port 0x80 I/O delay replacements we need
microseconds to be somewhat usefully defined pre calibration.
Initialize 386, 486 and Pentium 1 as fastest in their families
and higher CPUs (including 64-bit) at 1 Ghz. Note that trouble
should be absent past family 5 systems anyway.
Signed-off-by: Rene Herman <[EMAIL PROTECTED]>
diff --git a/arch/x86/kernel/time_32.c b/arch/x86/kernel/time_32.c
index 1a89e93..e33e70b 100644
--- a/arch/x86/kernel/time_32.c
+++ b/arch/x86/kernel/time_32.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
@@ -134,6 +135,17 @@ void __init hpet_time_init(void)
*/
void __init time_init(void)
{
+ switch (boot_cpu_data.x86) {
+ case 3:
+ loops_per_jiffy = LOOPS_PER_JIFFY_386;
+ break;
+ case 4:
+ loops_per_jiffy = LOOPS_PER_JIFFY_486;
+ break;
+ case 5:
+ loops_per_jiffy = LOOPS_PER_JIFFY_586;
+ break;
+ }
tsc_init();
late_time_init = choose_time_init();
}
diff --git a/include/asm-x86/delay.h b/include/asm-x86/delay.h
index 409a649..d0fbaf6 100644
--- a/include/asm-x86/delay.h
+++ b/include/asm-x86/delay.h
@@ -7,6 +7,11 @@
* Delay routines calling functions in arch/x86/lib/delay.c
*/
+#define LOOPS_PER_JIFFY_386(400 / HZ)/* 386 at 40 Mhz */
+#define LOOPS_PER_JIFFY_486(3000 / HZ) /* 486 at 120 MHz */
+#define LOOPS_PER_JIFFY_586(23300 / HZ) /* Pentium 1 at 233 Mhz */
+#define LOOPS_PER_JIFFY(10 / HZ) /* P6+ at 1 GHz */
+
/* Undefined functions to get compile-time errors */
extern void __bad_udelay(void);
extern void __bad_ndelay(void);
diff --git a/init/main.c b/init/main.c
index 8b19820..94862c8 100644
--- a/init/main.c
+++ b/init/main.c
@@ -228,12 +228,11 @@ static int __init obsolete_checksetup(char *line)
return had_early_param;
}
-/*
- * This should be approx 2 Bo*oMips to start (note initial shift), and will
- * still work even if initially too large, it will just take slightly longer
- */
-unsigned long loops_per_jiffy = (1<<12);
+#ifndef LOOPS_PER_JIFFY
+#define LOOPS_PER_JIFFY(1 << 12)
+#endif
+unsigned long loops_per_jiffy = LOOPS_PER_JIFFY;
EXPORT_SYMBOL(loops_per_jiffy);
static int __init debug_kernel(char *str)
Re: pnp_bus_resume(): inconsequent NULL checking
On 20-02-08 17:59, Bjorn Helgaas wrote:
I agree with you that we can just delete the dev->protocol tests
completely. So I'd rather see something like this (built but untested):
PNP: remove dev->protocol NULL checks
Every PNP device should have a valid protocol pointer. If it doesn't,
something's wrong and we should oops so we can find and fix the problem.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Ack from a functional standpoint: we are oopsing in pnp_start/stop_dev
_anyway_ if the protocol pointer isn't set.
Will you coach this upstream? A 2.6.25-rc1 change from me made the coverity
checker pick up on it which might be considered enough of an excuse to call
it a regression and submit this as a fix...
Index: work6/drivers/pnp/driver.c
===
--- work6.orig/drivers/pnp/driver.c 2008-02-20 09:46:01.0 -0700
+++ work6/drivers/pnp/driver.c 2008-02-20 09:46:28.0 -0700
@@ -167,7 +167,7 @@
return error;
}
- if (pnp_dev->protocol && pnp_dev->protocol->suspend)
+ if (pnp_dev->protocol->suspend)
pnp_dev->protocol->suspend(pnp_dev, state);
return 0;
}
@@ -181,7 +181,7 @@
if (!pnp_drv)
return 0;
- if (pnp_dev->protocol && pnp_dev->protocol->resume)
+ if (pnp_dev->protocol->resume)
pnp_dev->protocol->resume(pnp_dev);
if (pnp_can_write(pnp_dev)) {
Rene.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: use explicit timing delay for pit accesses in kernel and pcspkr driver
On 20-02-08 18:05, H. Peter Anvin wrote: Rene Herman wrote: _Something_ like this would seem to be the only remaining option. It seems fairly unuseful to #ifdef around that switch statement for kernels without support for the earlier families, but if you insist... "Only remaining option" other than the one we've had all along. Even on the one idiotic set of systems which break, it only breaks post-ACPI intialization, IIRC. Linus vetoed the DMI switch. Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: use explicit timing delay for pit accesses in kernel and pcspkr driver
On 18-02-08 23:44, H. Peter Anvin wrote:
Rene Herman wrote:
Yes, but generally not any P5+ system is going to need the PIT
delay in the first place meaning it just doesn't matter. There were
the VIA issues with the PIC but unless I missed it not with the PIT.
Uhm, I'm not sure I believe that's safe.
The PIT is particularly pissy in this case -- the semantics of the
PIT are ill-defined if there hasn't been a PIT clock between two
adjacent accesses, so I fully expect that there are chipsets out
there which will do very bad things in this case.
Okay. Now that they're isolated, do you have a suggestion for
{in,out}b_pit? You say a PIT clock, so do you think we can bounce of
the PIT iself in this case after all?
Am I correct that channel 1 is never used? A simple read from 0x41?
Channel 1 is available for the system. In modern systems, it's pretty
much available for the OS, although that's never formally stated (in the
original PC, it was used for DRAM refresh.)
However, I could very easily see a chipset have issues with that kind of
stuff.
I couldn't really, but clean it's neither. Okay, so you just want something
like this? This initializes loops_per_jiffy somewhat more usefully -- at a
1G CPU for P6 and 64-bit, and tuning it down again for 386/486/586.
The values taken are for what I believe to be the fastest CPUs among the
specific family. Alan?
386-40 and P1-233 were verified, the 486-120 value was scaled from a 486-40.
_Something_ like this would seem to be the only remaining option. It seems
fairly unuseful to #ifdef around that switch statement for kernels without
support for the earlier families, but if you insist...
Rene.
commit 9c679215248e837b34242632d5a22adf9a247021
Author: Rene Herman <[EMAIL PROTECTED]>
Date: Wed Feb 20 12:52:30 2008 +0100
x86: per CPU family loops_per_jiffy initialization
Following the current port 0x80 I/O delay replacements we need
microseconds to be somewhat usefully defined pre calibration.
Initialize 386, 486 and Pentium 1 as fastest in their families
and higher CPUs (including 64-bit) at 1 Ghz. Note that trouble
should be absent past family 5 systems anyway.
Signed-off-by: Rene Herman <[EMAIL PROTECTED]>
diff --git a/arch/x86/kernel/time_32.c b/arch/x86/kernel/time_32.c
index 1a89e93..e33e70b 100644
--- a/arch/x86/kernel/time_32.c
+++ b/arch/x86/kernel/time_32.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
@@ -134,6 +135,17 @@ void __init hpet_time_init(void)
*/
void __init time_init(void)
{
+ switch (boot_cpu_data.x86) {
+ case 3:
+ loops_per_jiffy = LOOPS_PER_JIFFY_386;
+ break;
+ case 4:
+ loops_per_jiffy = LOOPS_PER_JIFFY_486;
+ break;
+ case 5:
+ loops_per_jiffy = LOOPS_PER_JIFFY_586;
+ break;
+ }
tsc_init();
late_time_init = choose_time_init();
}
diff --git a/include/asm-x86/delay.h b/include/asm-x86/delay.h
index 409a649..d0fbaf6 100644
--- a/include/asm-x86/delay.h
+++ b/include/asm-x86/delay.h
@@ -7,6 +7,11 @@
* Delay routines calling functions in arch/x86/lib/delay.c
*/
+#define LOOPS_PER_JIFFY_386(400 / HZ)/* 386 at 40 Mhz */
+#define LOOPS_PER_JIFFY_486(3000 / HZ) /* 486 at 120 MHz */
+#define LOOPS_PER_JIFFY_586(23300 / HZ) /* Pentium 1 at 233 Mhz */
+#define LOOPS_PER_JIFFY(10 / HZ) /* P6+ at 1 GHz */
+
/* Undefined functions to get compile-time errors */
extern void __bad_udelay(void);
extern void __bad_ndelay(void);
diff --git a/init/main.c b/init/main.c
index 8b19820..94862c8 100644
--- a/init/main.c
+++ b/init/main.c
@@ -228,12 +228,11 @@ static int __init obsolete_checksetup(char *line)
return had_early_param;
}
-/*
- * This should be approx 2 Bo*oMips to start (note initial shift), and will
- * still work even if initially too large, it will just take slightly longer
- */
-unsigned long loops_per_jiffy = (1<<12);
+#ifndef LOOPS_PER_JIFFY
+#define LOOPS_PER_JIFFY(1 << 12)
+#endif
+unsigned long loops_per_jiffy = LOOPS_PER_JIFFY;
EXPORT_SYMBOL(loops_per_jiffy);
static int __init debug_kernel(char *str)
Re: [PATCH] x86: use explicit timing delay for pit accesses in kernel and pcspkr driver
On 18-02-08 23:44, H. Peter Anvin wrote:
Rene Herman wrote:
Yes, but generally not any P5+ system is going to need the PIT
delay in the first place meaning it just doesn't matter. There were
the VIA issues with the PIC but unless I missed it not with the PIT.
Uhm, I'm not sure I believe that's safe.
The PIT is particularly pissy in this case -- the semantics of the
PIT are ill-defined if there hasn't been a PIT clock between two
adjacent accesses, so I fully expect that there are chipsets out
there which will do very bad things in this case.
Okay. Now that they're isolated, do you have a suggestion for
{in,out}b_pit? You say a PIT clock, so do you think we can bounce of
the PIT iself in this case after all?
Am I correct that channel 1 is never used? A simple read from 0x41?
Channel 1 is available for the system. In modern systems, it's pretty
much available for the OS, although that's never formally stated (in the
original PC, it was used for DRAM refresh.)
However, I could very easily see a chipset have issues with that kind of
stuff.
I couldn't really, but clean it's neither. Okay, so you just want something
like this? This initializes loops_per_jiffy somewhat more usefully -- at a
1G CPU for P6 and 64-bit, and tuning it down again for 386/486/586.
The values taken are for what I believe to be the fastest CPUs among the
specific family. Alan?
386-40 and P1-233 were verified, the 486-120 value was scaled from a 486-40.
_Something_ like this would seem to be the only remaining option. It seems
fairly unuseful to #ifdef around that switch statement for kernels without
support for the earlier families, but if you insist...
Rene.
commit 9c679215248e837b34242632d5a22adf9a247021
Author: Rene Herman [EMAIL PROTECTED]
Date: Wed Feb 20 12:52:30 2008 +0100
x86: per CPU family loops_per_jiffy initialization
Following the current port 0x80 I/O delay replacements we need
microseconds to be somewhat usefully defined pre calibration.
Initialize 386, 486 and Pentium 1 as fastest in their families
and higher CPUs (including 64-bit) at 1 Ghz. Note that trouble
should be absent past family 5 systems anyway.
Signed-off-by: Rene Herman [EMAIL PROTECTED]
diff --git a/arch/x86/kernel/time_32.c b/arch/x86/kernel/time_32.c
index 1a89e93..e33e70b 100644
--- a/arch/x86/kernel/time_32.c
+++ b/arch/x86/kernel/time_32.c
@@ -32,6 +32,7 @@
#include linux/interrupt.h
#include linux/time.h
#include linux/mca.h
+#include linux/delay.h
#include asm/arch_hooks.h
#include asm/hpet.h
@@ -134,6 +135,17 @@ void __init hpet_time_init(void)
*/
void __init time_init(void)
{
+ switch (boot_cpu_data.x86) {
+ case 3:
+ loops_per_jiffy = LOOPS_PER_JIFFY_386;
+ break;
+ case 4:
+ loops_per_jiffy = LOOPS_PER_JIFFY_486;
+ break;
+ case 5:
+ loops_per_jiffy = LOOPS_PER_JIFFY_586;
+ break;
+ }
tsc_init();
late_time_init = choose_time_init();
}
diff --git a/include/asm-x86/delay.h b/include/asm-x86/delay.h
index 409a649..d0fbaf6 100644
--- a/include/asm-x86/delay.h
+++ b/include/asm-x86/delay.h
@@ -7,6 +7,11 @@
* Delay routines calling functions in arch/x86/lib/delay.c
*/
+#define LOOPS_PER_JIFFY_386(400 / HZ)/* 386 at 40 Mhz */
+#define LOOPS_PER_JIFFY_486(3000 / HZ) /* 486 at 120 MHz */
+#define LOOPS_PER_JIFFY_586(23300 / HZ) /* Pentium 1 at 233 Mhz */
+#define LOOPS_PER_JIFFY(10 / HZ) /* P6+ at 1 GHz */
+
/* Undefined functions to get compile-time errors */
extern void __bad_udelay(void);
extern void __bad_ndelay(void);
diff --git a/init/main.c b/init/main.c
index 8b19820..94862c8 100644
--- a/init/main.c
+++ b/init/main.c
@@ -228,12 +228,11 @@ static int __init obsolete_checksetup(char *line)
return had_early_param;
}
-/*
- * This should be approx 2 Bo*oMips to start (note initial shift), and will
- * still work even if initially too large, it will just take slightly longer
- */
-unsigned long loops_per_jiffy = (112);
+#ifndef LOOPS_PER_JIFFY
+#define LOOPS_PER_JIFFY(1 12)
+#endif
+unsigned long loops_per_jiffy = LOOPS_PER_JIFFY;
EXPORT_SYMBOL(loops_per_jiffy);
static int __init debug_kernel(char *str)
Re: [PATCH] x86: use explicit timing delay for pit accesses in kernel and pcspkr driver
On 20-02-08 18:05, H. Peter Anvin wrote: Rene Herman wrote: _Something_ like this would seem to be the only remaining option. It seems fairly unuseful to #ifdef around that switch statement for kernels without support for the earlier families, but if you insist... Only remaining option other than the one we've had all along. Even on the one idiotic set of systems which break, it only breaks post-ACPI intialization, IIRC. Linus vetoed the DMI switch. Rene. -- 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: pnp_bus_resume(): inconsequent NULL checking
On 20-02-08 17:59, Bjorn Helgaas wrote:
I agree with you that we can just delete the dev-protocol tests
completely. So I'd rather see something like this (built but untested):
PNP: remove dev-protocol NULL checks
Every PNP device should have a valid protocol pointer. If it doesn't,
something's wrong and we should oops so we can find and fix the problem.
Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED]
Ack from a functional standpoint: we are oopsing in pnp_start/stop_dev
_anyway_ if the protocol pointer isn't set.
Will you coach this upstream? A 2.6.25-rc1 change from me made the coverity
checker pick up on it which might be considered enough of an excuse to call
it a regression and submit this as a fix...
Index: work6/drivers/pnp/driver.c
===
--- work6.orig/drivers/pnp/driver.c 2008-02-20 09:46:01.0 -0700
+++ work6/drivers/pnp/driver.c 2008-02-20 09:46:28.0 -0700
@@ -167,7 +167,7 @@
return error;
}
- if (pnp_dev-protocol pnp_dev-protocol-suspend)
+ if (pnp_dev-protocol-suspend)
pnp_dev-protocol-suspend(pnp_dev, state);
return 0;
}
@@ -181,7 +181,7 @@
if (!pnp_drv)
return 0;
- if (pnp_dev-protocol pnp_dev-protocol-resume)
+ if (pnp_dev-protocol-resume)
pnp_dev-protocol-resume(pnp_dev);
if (pnp_can_write(pnp_dev)) {
Rene.
--
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: [linux-kernel] Re: [PATCH] x86: use explicit timing delay for pit accesses in kernel and pcspkr driver
On 20-02-08 21:13, David P. Reed wrote:
Actually, disparaging things as one idiotic system doesn't seem like a
long-term thoughtful process - it's not even accurate.
Whatever we think about systems using port 0x80, fact of the matter is that
they do and outside of legacy stuff that isn't applicable to these systems,
Linux needs to stop using it (post ACPI init at least) to be able to run on
them.
As options of doing so we have:
1) Replace the port 0x80 I/O delay with nothing. Determined to be unsafe.
2) Replace 0x80 with another port. None are really available and DMI based
switching gets to be unmaintainable and has a such been shot down.
3) Replace the port 0x80 I/O delay with a udelay(2). Should work well enough
in practice for the remaining users outside legacy drivers after (Alan's)
cleaning up.
The remaining (possible) problem is that pre calibration microseconds are a
total fiction and at least PIT init happens before calibration. In practice
I believe this might not be much of a real-world problem since for whatever
initial value for loops_per_jiffy we get at least our old double short jump
that is enough of a delay for 386 and 486 but I sympathise with anone, such
as HPA, who'd consider my beliefs not a particular guarantee.
So, we need a more useful pre calibration udelay. Ugly as it might be,
through something like the attached. Alan, could you perhaps comment?
With the problam surfacing only post ACPI init, the _last_ remaining option
is talking to the PIT using port 0x80 at init and using udelay after but I
myself will not be submitting a patch to do so. Insane mess.
It would be good to get this crap sorted relatively quickly so we can do
away with the io_delay mongering even pre .26 again. It introduces boot
parameters and as such becomes part of API somewhat, so if it's not going to
stay let's kill it quickly.
Ren
commit 9c679215248e837b34242632d5a22adf9a247021
Author: Rene Herman [EMAIL PROTECTED]
Date: Wed Feb 20 12:52:30 2008 +0100
x86: per CPU family loops_per_jiffy initialization
Following the current port 0x80 I/O delay replacements we need
microseconds to be somewhat usefully defined pre calibration.
Initialize 386, 486 and Pentium 1 as fastest in their families
and higher CPUs (including 64-bit) at 1 Ghz. Note that trouble
should be absent past family 5 systems anyway.
Signed-off-by: Rene Herman [EMAIL PROTECTED]
diff --git a/arch/x86/kernel/time_32.c b/arch/x86/kernel/time_32.c
index 1a89e93..e33e70b 100644
--- a/arch/x86/kernel/time_32.c
+++ b/arch/x86/kernel/time_32.c
@@ -32,6 +32,7 @@
#include linux/interrupt.h
#include linux/time.h
#include linux/mca.h
+#include linux/delay.h
#include asm/arch_hooks.h
#include asm/hpet.h
@@ -134,6 +135,17 @@ void __init hpet_time_init(void)
*/
void __init time_init(void)
{
+ switch (boot_cpu_data.x86) {
+ case 3:
+ loops_per_jiffy = LOOPS_PER_JIFFY_386;
+ break;
+ case 4:
+ loops_per_jiffy = LOOPS_PER_JIFFY_486;
+ break;
+ case 5:
+ loops_per_jiffy = LOOPS_PER_JIFFY_586;
+ break;
+ }
tsc_init();
late_time_init = choose_time_init();
}
diff --git a/include/asm-x86/delay.h b/include/asm-x86/delay.h
index 409a649..d0fbaf6 100644
--- a/include/asm-x86/delay.h
+++ b/include/asm-x86/delay.h
@@ -7,6 +7,11 @@
* Delay routines calling functions in arch/x86/lib/delay.c
*/
+#define LOOPS_PER_JIFFY_386(400 / HZ)/* 386 at 40 Mhz */
+#define LOOPS_PER_JIFFY_486(3000 / HZ) /* 486 at 120 MHz */
+#define LOOPS_PER_JIFFY_586(23300 / HZ) /* Pentium 1 at 233 Mhz */
+#define LOOPS_PER_JIFFY(10 / HZ) /* P6+ at 1 GHz */
+
/* Undefined functions to get compile-time errors */
extern void __bad_udelay(void);
extern void __bad_ndelay(void);
diff --git a/init/main.c b/init/main.c
index 8b19820..94862c8 100644
--- a/init/main.c
+++ b/init/main.c
@@ -228,12 +228,11 @@ static int __init obsolete_checksetup(char *line)
return had_early_param;
}
-/*
- * This should be approx 2 Bo*oMips to start (note initial shift), and will
- * still work even if initially too large, it will just take slightly longer
- */
-unsigned long loops_per_jiffy = (112);
+#ifndef LOOPS_PER_JIFFY
+#define LOOPS_PER_JIFFY(1 12)
+#endif
+unsigned long loops_per_jiffy = LOOPS_PER_JIFFY;
EXPORT_SYMBOL(loops_per_jiffy);
static int __init debug_kernel(char *str)
Re: pnp_bus_resume(): inconsequent NULL checking
On 19-02-08 23:49, Adrian Bunk wrote:
The Coverity checker spotted the following inconsequent NULL checking
introduced by commit 5d38998ed15b31f524bde9a193d60150af30d916:
<-- snip -->
...
static int pnp_bus_resume(struct device *dev)
{
...
if (pnp_dev->protocol && pnp_dev->protocol->resume)
pnp_dev->protocol->resume(pnp_dev);
if (pnp_can_write(pnp_dev)) {
...
<-- snip -->
pnp_can_write(pnp_dev) dereferences pnp_dev->protocol.
I see, thanks. pnp_bus_suspend() has the same problem (I added this test to
complete the mirror in fact) and/but is not a real problem since the tests
are also the first things done inside the blocks they protect -- if
pnp_dev->protocol isn't set here, we're dead anyway therefore.
That probably means we can just delete the pnp_dev->protocol tests but this
would need an ack from for example Bjorn Helgaas who might have an idea
about how generically useful this is designed to be. The no brain thing to
do would be just as per attached.
Bjorn?
pnp: be consistent about testing pnp_dev->protocol in pnp_bus_{suspend,resume}
pnp_can_{disable,write}() dereference pnp_dev->protocol. So do the
pnp_{stop,start}_dev() the tests protect, but let's be consistent
at least.
Spotted by Adrian Bunk <[EMAIL PROTECTED]> and the Coverity checker.
Signed-off-by: Rene Herman <[EMAIL PROTECTED]>
diff --git a/drivers/pnp/driver.c b/drivers/pnp/driver.c
index 12a1645..170af61 100644
--- a/drivers/pnp/driver.c
+++ b/drivers/pnp/driver.c
@@ -160,15 +160,15 @@ static int pnp_bus_suspend(struct device *dev,
pm_message_t state)
if (error)
return error;
}
-
- if (pnp_can_disable(pnp_dev)) {
- error = pnp_stop_dev(pnp_dev);
- if (error)
- return error;
+ if (pnp_dev->protocol) {
+ if (pnp_can_disable(pnp_dev)) {
+ error = pnp_stop_dev(pnp_dev);
+ if (error)
+ return error;
+ }
+ if (pnp_dev->protocol->suspend)
+ pnp_dev->protocol->suspend(pnp_dev, state);
}
-
- if (pnp_dev->protocol && pnp_dev->protocol->suspend)
- pnp_dev->protocol->suspend(pnp_dev, state);
return 0;
}
@@ -181,21 +181,21 @@ static int pnp_bus_resume(struct device *dev)
if (!pnp_drv)
return 0;
- if (pnp_dev->protocol && pnp_dev->protocol->resume)
- pnp_dev->protocol->resume(pnp_dev);
+ if (pnp_dev->protocol) {
+ if (pnp_dev->protocol->resume)
+ pnp_dev->protocol->resume(pnp_dev);
- if (pnp_can_write(pnp_dev)) {
- error = pnp_start_dev(pnp_dev);
- if (error)
- return error;
+ if (pnp_can_write(pnp_dev)) {
+ error = pnp_start_dev(pnp_dev);
+ if (error)
+ return error;
+ }
}
-
if (pnp_drv->resume) {
error = pnp_drv->resume(pnp_dev);
if (error)
return error;
}
-
return 0;
}
Re: pnp_bus_resume(): inconsequent NULL checking
On 19-02-08 23:49, Adrian Bunk wrote:
The Coverity checker spotted the following inconsequent NULL checking
introduced by commit 5d38998ed15b31f524bde9a193d60150af30d916:
-- snip --
...
static int pnp_bus_resume(struct device *dev)
{
...
if (pnp_dev-protocol pnp_dev-protocol-resume)
pnp_dev-protocol-resume(pnp_dev);
if (pnp_can_write(pnp_dev)) {
...
-- snip --
pnp_can_write(pnp_dev) dereferences pnp_dev-protocol.
I see, thanks. pnp_bus_suspend() has the same problem (I added this test to
complete the mirror in fact) and/but is not a real problem since the tests
are also the first things done inside the blocks they protect -- if
pnp_dev-protocol isn't set here, we're dead anyway therefore.
That probably means we can just delete the pnp_dev-protocol tests but this
would need an ack from for example Bjorn Helgaas who might have an idea
about how generically useful this is designed to be. The no brain thing to
do would be just as per attached.
Bjorn?
pnp: be consistent about testing pnp_dev-protocol in pnp_bus_{suspend,resume}
pnp_can_{disable,write}() dereference pnp_dev-protocol. So do the
pnp_{stop,start}_dev() the tests protect, but let's be consistent
at least.
Spotted by Adrian Bunk [EMAIL PROTECTED] and the Coverity checker.
Signed-off-by: Rene Herman [EMAIL PROTECTED]
diff --git a/drivers/pnp/driver.c b/drivers/pnp/driver.c
index 12a1645..170af61 100644
--- a/drivers/pnp/driver.c
+++ b/drivers/pnp/driver.c
@@ -160,15 +160,15 @@ static int pnp_bus_suspend(struct device *dev,
pm_message_t state)
if (error)
return error;
}
-
- if (pnp_can_disable(pnp_dev)) {
- error = pnp_stop_dev(pnp_dev);
- if (error)
- return error;
+ if (pnp_dev-protocol) {
+ if (pnp_can_disable(pnp_dev)) {
+ error = pnp_stop_dev(pnp_dev);
+ if (error)
+ return error;
+ }
+ if (pnp_dev-protocol-suspend)
+ pnp_dev-protocol-suspend(pnp_dev, state);
}
-
- if (pnp_dev-protocol pnp_dev-protocol-suspend)
- pnp_dev-protocol-suspend(pnp_dev, state);
return 0;
}
@@ -181,21 +181,21 @@ static int pnp_bus_resume(struct device *dev)
if (!pnp_drv)
return 0;
- if (pnp_dev-protocol pnp_dev-protocol-resume)
- pnp_dev-protocol-resume(pnp_dev);
+ if (pnp_dev-protocol) {
+ if (pnp_dev-protocol-resume)
+ pnp_dev-protocol-resume(pnp_dev);
- if (pnp_can_write(pnp_dev)) {
- error = pnp_start_dev(pnp_dev);
- if (error)
- return error;
+ if (pnp_can_write(pnp_dev)) {
+ error = pnp_start_dev(pnp_dev);
+ if (error)
+ return error;
+ }
}
-
if (pnp_drv-resume) {
error = pnp_drv-resume(pnp_dev);
if (error)
return error;
}
-
return 0;
}
Re: [PATCH] x86: use explicit timing delay for pit accesses in kernel and pcspkr driver
On 18-02-08 23:07, Rene Herman wrote:
On 18-02-08 23:01, H. Peter Anvin wrote:
Rene Herman wrote:
Yes, but generally not any P5+ system is going to need the PIT delay
in the first place meaning it just doesn't matter. There were the VIA
issues with the PIC but unless I missed it not with the PIT.
Uhm, I'm not sure I believe that's safe.
The PIT is particularly pissy in this case -- the semantics of the PIT
are ill-defined if there hasn't been a PIT clock between two adjacent
accesses, so I fully expect that there are chipsets out there which
will do very bad things in this case.
Okay. Now that they're isolated, do you have a suggestion for
{in,out}b_pit? You say a PIT clock, so do you think we can bounce of the
PIT iself in this case after all?
Am I correct that channel 1 is never used? A simple read from 0x41?
Rene.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: use explicit timing delay for pit accesses in kernel and pcspkr driver
On 18-02-08 23:01, H. Peter Anvin wrote:
Rene Herman wrote:
Yes, but generally not any P5+ system is going to need the PIT delay
in the first place meaning it just doesn't matter. There were the VIA
issues with the PIC but unless I missed it not with the PIT.
Uhm, I'm not sure I believe that's safe.
The PIT is particularly pissy in this case -- the semantics of the PIT
are ill-defined if there hasn't been a PIT clock between two adjacent
accesses, so I fully expect that there are chipsets out there which will
do very bad things in this case.
Okay. Now that they're isolated, do you have a suggestion for {in,out}b_pit?
You say a PIT clock, so do you think we can bounce of the PIT iself in this
case after all?
Rene.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: use explicit timing delay for pit accesses in kernel and pcspkr driver
On 18-02-08 22:44, H. Peter Anvin wrote: Rene Herman wrote: I mean that before the linux kernel used a port 0x80 write as an I/O delay it used a short jump (two in a row actually...) as such and this was at the time that it actually ran on the old legacy stuff that is of most concern here. No, if I'm not mistaken, those two jumps are actually what the udelay() is going to do anyway as part of delay_loop() at that early stage so that even before loops_per_jiffy calibration, I believe we should still be okay. That doesn't make any sense at all. The whole point why the two jumps were obsoleted with the P5 (or even late P4, if I'm not mistaken) was because they were utterly insufficient when the CPU ran at something much higher than the external speed. Yes, but generally not any P5+ system is going to need the PIT delay in the first place meaning it just doesn't matter. There were the VIA issues with the PIC but unless I missed it not with the PIT. That's the point. It's fairly unclean to say udelay(2) and then not delay for 2 microseconds but you _have_ done the two short jumps meaning 386 and 486 systems are okay and later systems were okay to start with. Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: use explicit timing delay for pit accesses in kernel and pcspkr driver
On 18-02-08 22:04, Rene Herman wrote: On 18-02-08 21:43, H. Peter Anvin wrote: Rene Herman wrote: Now with respect to the original pre port 80 "jmp $+2" I/O delay (which the Pentium obsoleted) I suppose it'll probably be okay even without fixing that specifically but do note such -- it's a vital part of the problem. Sorry, that paragraph didn't parse for me. I mean that before the linux kernel used a port 0x80 write as an I/O delay it used a short jump (two in a row actually...) as such and this was at the time that it actually ran on the old legacy stuff that is of most concern here. No, if I'm not mistaken, those two jumps are actually what the udelay() _Now_, if I'm ... is going to do anyway as part of delay_loop() at that early stage so that even before loops_per_jiffy calibration, I believe we should still be okay. Yes, it's a bit of a "well, hrrm" thing, but, well... loops_per_jiffy can be initialised a bit more conservatively then today as well (and as discussed earlier, possibly per CPU family) but I believe it's actually sort of fine not too worry much about it... Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: use explicit timing delay for pit accesses in kernel and pcspkr driver
On 18-02-08 21:43, H. Peter Anvin wrote: Rene Herman wrote: Now with respect to the original pre port 80 "jmp $+2" I/O delay (which the Pentium obsoleted) I suppose it'll probably be okay even without fixing that specifically but do note such -- it's a vital part of the problem. Sorry, that paragraph didn't parse for me. I mean that before the linux kernel used a port 0x80 write as an I/O delay it used a short jump (two in a row actually...) as such and this was at the time that it actually ran on the old legacy stuff that is of most concern here. No, if I'm not mistaken, those two jumps are actually what the udelay() is going to do anyway as part of delay_loop() at that early stage so that even before loops_per_jiffy calibration, I believe we should still be okay. Yes, it's a bit of a "well, hrrm" thing, but, well... loops_per_jiffy can be initialised a bit more conservatively then today as well (and as discussed earlier, possibly per CPU family) but I believe it's actually sort of fine not too worry much about it... Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: use explicit timing delay for pit accesses in kernel and pcspkr driver
On 18-02-08 19:58, David P. Reed wrote:
--- linux-2.6.orig/include/asm-x86/i8253.h
+++ linux-2.6/include/asm-x86/i8253.h
@@ -12,7 +12,25 @@ extern struct clock_event_device *global
extern void setup_pit_timer(void);
-#define inb_pit inb_p
-#define outb_pit outb_p
+/* accesses to PIT registers need careful delays on some platforms. Define
+ them here in a common place */
+static inline unsigned char inb_pit(unsigned int port)
+{
+ /* delay for some accesses to PIT on motherboard or in chipset must be
+ at least one microsecond, but be safe here. */
+ unsigned char value = inb(port);
+ udelay(2);
+ return value;
+}
With the remark that (at least) the PIT is accessed at a time that
microseconds and hence udelay are still a total fiction, this looks obvious
otherwise.
Now with respect to the original pre port 80 "jmp $+2" I/O delay (which the
Pentium obsoleted) I suppose it'll probably be okay even without fixing that
specifically but do note such -- it's a vital part of the problem.
Rene.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: use explicit timing delay for pit accesses in kernel and pcspkr driver
On 18-02-08 19:58, David P. Reed wrote:
--- linux-2.6.orig/include/asm-x86/i8253.h
+++ linux-2.6/include/asm-x86/i8253.h
@@ -12,7 +12,25 @@ extern struct clock_event_device *global
extern void setup_pit_timer(void);
-#define inb_pit inb_p
-#define outb_pit outb_p
+/* accesses to PIT registers need careful delays on some platforms. Define
+ them here in a common place */
+static inline unsigned char inb_pit(unsigned int port)
+{
+ /* delay for some accesses to PIT on motherboard or in chipset must be
+ at least one microsecond, but be safe here. */
+ unsigned char value = inb(port);
+ udelay(2);
+ return value;
+}
With the remark that (at least) the PIT is accessed at a time that
microseconds and hence udelay are still a total fiction, this looks obvious
otherwise.
Now with respect to the original pre port 80 jmp $+2 I/O delay (which the
Pentium obsoleted) I suppose it'll probably be okay even without fixing that
specifically but do note such -- it's a vital part of the problem.
Rene.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: use explicit timing delay for pit accesses in kernel and pcspkr driver
On 18-02-08 22:04, Rene Herman wrote: On 18-02-08 21:43, H. Peter Anvin wrote: Rene Herman wrote: Now with respect to the original pre port 80 jmp $+2 I/O delay (which the Pentium obsoleted) I suppose it'll probably be okay even without fixing that specifically but do note such -- it's a vital part of the problem. Sorry, that paragraph didn't parse for me. I mean that before the linux kernel used a port 0x80 write as an I/O delay it used a short jump (two in a row actually...) as such and this was at the time that it actually ran on the old legacy stuff that is of most concern here. No, if I'm not mistaken, those two jumps are actually what the udelay() _Now_, if I'm ... is going to do anyway as part of delay_loop() at that early stage so that even before loops_per_jiffy calibration, I believe we should still be okay. Yes, it's a bit of a well, hrrm thing, but, well... loops_per_jiffy can be initialised a bit more conservatively then today as well (and as discussed earlier, possibly per CPU family) but I believe it's actually sort of fine not too worry much about it... Rene. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: use explicit timing delay for pit accesses in kernel and pcspkr driver
On 18-02-08 21:43, H. Peter Anvin wrote: Rene Herman wrote: Now with respect to the original pre port 80 jmp $+2 I/O delay (which the Pentium obsoleted) I suppose it'll probably be okay even without fixing that specifically but do note such -- it's a vital part of the problem. Sorry, that paragraph didn't parse for me. I mean that before the linux kernel used a port 0x80 write as an I/O delay it used a short jump (two in a row actually...) as such and this was at the time that it actually ran on the old legacy stuff that is of most concern here. No, if I'm not mistaken, those two jumps are actually what the udelay() is going to do anyway as part of delay_loop() at that early stage so that even before loops_per_jiffy calibration, I believe we should still be okay. Yes, it's a bit of a well, hrrm thing, but, well... loops_per_jiffy can be initialised a bit more conservatively then today as well (and as discussed earlier, possibly per CPU family) but I believe it's actually sort of fine not too worry much about it... Rene. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: use explicit timing delay for pit accesses in kernel and pcspkr driver
On 18-02-08 23:01, H. Peter Anvin wrote:
Rene Herman wrote:
Yes, but generally not any P5+ system is going to need the PIT delay
in the first place meaning it just doesn't matter. There were the VIA
issues with the PIC but unless I missed it not with the PIT.
Uhm, I'm not sure I believe that's safe.
The PIT is particularly pissy in this case -- the semantics of the PIT
are ill-defined if there hasn't been a PIT clock between two adjacent
accesses, so I fully expect that there are chipsets out there which will
do very bad things in this case.
Okay. Now that they're isolated, do you have a suggestion for {in,out}b_pit?
You say a PIT clock, so do you think we can bounce of the PIT iself in this
case after all?
Rene.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: use explicit timing delay for pit accesses in kernel and pcspkr driver
On 18-02-08 22:44, H. Peter Anvin wrote: Rene Herman wrote: I mean that before the linux kernel used a port 0x80 write as an I/O delay it used a short jump (two in a row actually...) as such and this was at the time that it actually ran on the old legacy stuff that is of most concern here. No, if I'm not mistaken, those two jumps are actually what the udelay() is going to do anyway as part of delay_loop() at that early stage so that even before loops_per_jiffy calibration, I believe we should still be okay. That doesn't make any sense at all. The whole point why the two jumps were obsoleted with the P5 (or even late P4, if I'm not mistaken) was because they were utterly insufficient when the CPU ran at something much higher than the external speed. Yes, but generally not any P5+ system is going to need the PIT delay in the first place meaning it just doesn't matter. There were the VIA issues with the PIC but unless I missed it not with the PIT. That's the point. It's fairly unclean to say udelay(2) and then not delay for 2 microseconds but you _have_ done the two short jumps meaning 386 and 486 systems are okay and later systems were okay to start with. Rene. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: use explicit timing delay for pit accesses in kernel and pcspkr driver
On 18-02-08 23:07, Rene Herman wrote:
On 18-02-08 23:01, H. Peter Anvin wrote:
Rene Herman wrote:
Yes, but generally not any P5+ system is going to need the PIT delay
in the first place meaning it just doesn't matter. There were the VIA
issues with the PIC but unless I missed it not with the PIT.
Uhm, I'm not sure I believe that's safe.
The PIT is particularly pissy in this case -- the semantics of the PIT
are ill-defined if there hasn't been a PIT clock between two adjacent
accesses, so I fully expect that there are chipsets out there which
will do very bad things in this case.
Okay. Now that they're isolated, do you have a suggestion for
{in,out}b_pit? You say a PIT clock, so do you think we can bounce of the
PIT iself in this case after all?
Am I correct that channel 1 is never used? A simple read from 0x41?
Rene.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] x86: fix init_8259A() to not use outb_pic
On 17-02-08 23:25, Alan Cox wrote: On Sun, 17 Feb 2008 16:56:28 -0500 (EST) "David P. Reed" <[EMAIL PROTECTED]> wrote: fix init_8259A() which initializes the 8259 PIC to not use outb_pic, which is a renamed version of outb_p, and delete outb_pic define. NAK The entire point of inb_pic/outb_pic is to isolate the various methods and keep the logic for delays in one place. Undoing this just creates a nasty mess. Quite probably inb_pic/outb_pic will end up as static inlines that do inb or outb with a udelay of 1 or 2 but that is where the knowledge belongs. Additional NAK in sofar that the PIC delays were reported to be necesary with some VIA chipsets earlier in these threads. Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] x86: fix init_8259A() to not use outb_pic
On 17-02-08 23:25, Alan Cox wrote: On Sun, 17 Feb 2008 16:56:28 -0500 (EST) David P. Reed [EMAIL PROTECTED] wrote: fix init_8259A() which initializes the 8259 PIC to not use outb_pic, which is a renamed version of outb_p, and delete outb_pic define. NAK The entire point of inb_pic/outb_pic is to isolate the various methods and keep the logic for delays in one place. Undoing this just creates a nasty mess. Quite probably inb_pic/outb_pic will end up as static inlines that do inb or outb with a udelay of 1 or 2 but that is where the knowledge belongs. Additional NAK in sofar that the PIC delays were reported to be necesary with some VIA chipsets earlier in these threads. Rene. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] kernel/{exit.c, signal.c, power/process.c}: replace !likely(x) by likely(!x)
On 17-02-08 04:56, H. Peter Anvin wrote: Rene Herman wrote: On 16-02-08 20:01, H. Peter Anvin wrote: Roel Kluin wrote: Not entirely sure who to send this to --- Replace !likely(x) by likely(!x) Whoa... Are you sure this is correct? !likely(x) is equivalent to unlikely(!x) Not with respect to its value I believe? likely(x) == !!(x), and unlikely(!x) == !!(!x) = !x, so conditions work out differently? You missed one ! sign: !likely(x) == !!!(x) == unlikely(!x) == !!(!(x)) Yup, sorry, misread. Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] kernel/{exit.c, signal.c, power/process.c}: replace !likely(x) by likely(!x)
On 16-02-08 20:01, H. Peter Anvin wrote: Roel Kluin wrote: Not entirely sure who to send this to --- Replace !likely(x) by likely(!x) Whoa... Are you sure this is correct? !likely(x) is equivalent to unlikely(!x) Not with respect to its value I believe? likely(x) == !!(x), and unlikely(!x) == !!(!x) = !x, so conditions work out differently? not the opposite, so this is a functional change... Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] kernel/{exit.c, signal.c, power/process.c}: replace !likely(x) by likely(!x)
On 16-02-08 20:01, H. Peter Anvin wrote: Roel Kluin wrote: Not entirely sure who to send this to --- Replace !likely(x) by likely(!x) Whoa... Are you sure this is correct? !likely(x) is equivalent to unlikely(!x) Not with respect to its value I believe? likely(x) == !!(x), and unlikely(!x) == !!(!x) = !x, so conditions work out differently? not the opposite, so this is a functional change... Rene. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] kernel/{exit.c, signal.c, power/process.c}: replace !likely(x) by likely(!x)
On 17-02-08 04:56, H. Peter Anvin wrote: Rene Herman wrote: On 16-02-08 20:01, H. Peter Anvin wrote: Roel Kluin wrote: Not entirely sure who to send this to --- Replace !likely(x) by likely(!x) Whoa... Are you sure this is correct? !likely(x) is equivalent to unlikely(!x) Not with respect to its value I believe? likely(x) == !!(x), and unlikely(!x) == !!(!x) = !x, so conditions work out differently? You missed one ! sign: !likely(x) == !!!(x) == unlikely(!x) == !!(!(x)) Yup, sorry, misread. Rene. -- 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.25-rc2 vdso_install breaks user "make install"
On 16-02-08 04:42, Roland McGrath wrote: Perhaps it makes more sense to have vdso_install be a dependency of modules_install rather than install, since they both put things in /lib/modules. Would work for me -- modules_install ofcourse runs as root. The installed vdso images are potentially useful for a kernel when you aren't bothering to build or install any modules, but those images are only ever useful for sophisticated debugging uses anyway. Sam, any thoughts? (See arch/x86/Makefile and arch/powerpc/Makefile.) Or maybe update the installkernel "protocol" to add these in? The only kind of install runs I actually care about are for packaging system builds. There the packaged build does 'make vdso_install' explicitly anyway (at least Fedora rpms' .spec does). So if the consensus is just to drop the dependency on vdso_install completely, I don't object. Did that for now... Rene. -- 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/
2.6.25-rc2 vdso_install breaks user "make install"
Good day. I have a ~/bin/installkernel which installs the kernel when I as user do a make install at the end of compilation but 2.6.25-rc2 seems to break this: [EMAIL PROTECTED]:~/src/linux/local$ make V=1 install make -f scripts/Makefile.build obj=arch/x86/vdso vdso_install mkdir: cannot create directory `/lib/modules/2.6.25-rc2': Permission denied How to fix? Rene. -- 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/
2.6.25-rc2 vdso_install breaks user make install
Good day. I have a ~/bin/installkernel which installs the kernel when I as user do a make install at the end of compilation but 2.6.25-rc2 seems to break this: [EMAIL PROTECTED]:~/src/linux/local$ make V=1 install make -f scripts/Makefile.build obj=arch/x86/vdso vdso_install mkdir: cannot create directory `/lib/modules/2.6.25-rc2': Permission denied How to fix? Rene. -- 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.25-rc2 vdso_install breaks user make install
On 16-02-08 04:42, Roland McGrath wrote: Perhaps it makes more sense to have vdso_install be a dependency of modules_install rather than install, since they both put things in /lib/modules. Would work for me -- modules_install ofcourse runs as root. The installed vdso images are potentially useful for a kernel when you aren't bothering to build or install any modules, but those images are only ever useful for sophisticated debugging uses anyway. Sam, any thoughts? (See arch/x86/Makefile and arch/powerpc/Makefile.) Or maybe update the installkernel protocol to add these in? The only kind of install runs I actually care about are for packaging system builds. There the packaged build does 'make vdso_install' explicitly anyway (at least Fedora rpms' .spec does). So if the consensus is just to drop the dependency on vdso_install completely, I don't object. Did that for now... Rene. -- 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: Feature Removals for 2.6.25
On 15-02-08 00:20, David Newall wrote: Arjan van de Ven wrote: Bill Davidsen wrote: Note that because the hardware is old, it's highly likely that most of it will be retired before that sk98lin driver needs a change. I can't see anyone using sk98lin on a new system, so it would be less contentious to let the hardware (or users) die of natural causes if you can. the problem is that the new one DOES NOT GET FIXED. THAT is a huge problem; it means we have a buggy driver... If the old one works and the new one is buggy, it begs the question of why anybody bothered writing a new one in the first place. "If it ain't broke, don't fix it," might have been good advice to follow. Not generally. A usual scenario is the new driver working on newer hardware versions than the old one supports but not necessarily on all the old ones the previous driver supported if only due to to availability of the older hardware for testing. Rene. -- 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 PATCH] feature-removal: add documentation for exported symbols going away
On 13-02-08 23:22, Harvey Harrison wrote: +--- + +What: io_delay_type +Where: arch/x86/kernel/io_delay.c +When: 2.6.28 +Why: No in tree users The entirety of io_delay.c should be gone long before .28. It's a short term thing till the port 0x80 problems have been dealt with. Rene. -- 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 PATCH] feature-removal: add documentation for exported symbols going away
On 13-02-08 23:22, Harvey Harrison wrote: +--- + +What: io_delay_type +Where: arch/x86/kernel/io_delay.c +When: 2.6.28 +Why: No in tree users The entirety of io_delay.c should be gone long before .28. It's a short term thing till the port 0x80 problems have been dealt with. Rene. -- 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: Feature Removals for 2.6.25
On 15-02-08 00:20, David Newall wrote: Arjan van de Ven wrote: Bill Davidsen wrote: Note that because the hardware is old, it's highly likely that most of it will be retired before that sk98lin driver needs a change. I can't see anyone using sk98lin on a new system, so it would be less contentious to let the hardware (or users) die of natural causes if you can. the problem is that the new one DOES NOT GET FIXED. THAT is a huge problem; it means we have a buggy driver... If the old one works and the new one is buggy, it begs the question of why anybody bothered writing a new one in the first place. If it ain't broke, don't fix it, might have been good advice to follow. Not generally. A usual scenario is the new driver working on newer hardware versions than the old one supports but not necessarily on all the old ones the previous driver supported if only due to to availability of the older hardware for testing. Rene. -- 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: "ide=reverse" do we still need this?
On 13-02-08 13:06, Rene Herman wrote: On 13-02-08 05:44, Greg KH wrote: While details escape me somewhat again at the monment, a few months ago I was playing around with a PCI Promise IDE controller and needed ide=reverse to save me from having to switch disks around to still have a bootable system. Or some such. Not too clear anymore, but I remember it saved the day. You couldn't just change the boot disk in grub? Or use an initramfs and /dev/disk/by-id/ to keep any future moves stable? No. The thing is that you need these kinds of hacks while messing with old systems, building and stripping them, often in recovery type of situations. As said (same as the other person I saw reacting) details of what was most decidedly needed last time around escape me at the moment, but ide=reverse is the kind of hack that saves one hours of unscrewing computer cases and switching disks around while building stuff, making quick tests, doing recovery... If it must go for the greater architectural good, so be it, but it's the type of thing that's used specifically in the situations where you don't have stable, well arranged (or known!) setups to begin with. Allow me to add that the demise of drivers/ide itself is an argument for just shooting the thing if it helps clean up the API. Next year when I'm messing with that Promise controller again, the machine might very well be running a kernel using PATA instead of IDE anyway... Rene. -- 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: "ide=reverse" do we still need this?
On 13-02-08 13:16, Michael Ellerman wrote: On Wed, 2008-02-13 at 13:06 +0100, Rene Herman wrote: On 13-02-08 05:44, Greg KH wrote: While details escape me somewhat again at the monment, a few months ago I was playing around with a PCI Promise IDE controller and needed ide=reverse to save me from having to switch disks around to still have a bootable system. Or some such. Not too clear anymore, but I remember it saved the day. You couldn't just change the boot disk in grub? Or use an initramfs and /dev/disk/by-id/ to keep any future moves stable? No. The thing is that you need these kinds of hacks while messing with old systems, building and stripping them, often in recovery type of situations. As said (same as the other person I saw reacting) details of what was most decidedly needed last time around escape me at the moment, but ide=reverse is the kind of hack that saves one hours of unscrewing computer cases and switching disks around while building stuff, making quick tests, doing recovery... If it must go for the greater architectural good, so be it, but it's the type of thing that's used specifically in the situations where you don't have stable, well arranged (or known!) setups to begin with. I might be off the deep end, but isn't this what Documentation/feature-removal-schedule.txt is for? Documentation/feature-removal-schedule.txt is for asking/discussing whether or not features should be removed? No, I don't think so. It seems to be a schedule of when to remove features. Rene. -- 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: "ide=reverse" do we still need this?
On 13-02-08 05:44, Greg KH wrote: While details escape me somewhat again at the monment, a few months ago I was playing around with a PCI Promise IDE controller and needed ide=reverse to save me from having to switch disks around to still have a bootable system. Or some such. Not too clear anymore, but I remember it saved the day. You couldn't just change the boot disk in grub? Or use an initramfs and /dev/disk/by-id/ to keep any future moves stable? No. The thing is that you need these kinds of hacks while messing with old systems, building and stripping them, often in recovery type of situations. As said (same as the other person I saw reacting) details of what was most decidedly needed last time around escape me at the moment, but ide=reverse is the kind of hack that saves one hours of unscrewing computer cases and switching disks around while building stuff, making quick tests, doing recovery... If it must go for the greater architectural good, so be it, but it's the type of thing that's used specifically in the situations where you don't have stable, well arranged (or known!) setups to begin with. Rene. -- 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: ide=reverse do we still need this?
On 13-02-08 13:16, Michael Ellerman wrote: On Wed, 2008-02-13 at 13:06 +0100, Rene Herman wrote: On 13-02-08 05:44, Greg KH wrote: While details escape me somewhat again at the monment, a few months ago I was playing around with a PCI Promise IDE controller and needed ide=reverse to save me from having to switch disks around to still have a bootable system. Or some such. Not too clear anymore, but I remember it saved the day. You couldn't just change the boot disk in grub? Or use an initramfs and /dev/disk/by-id/ to keep any future moves stable? No. The thing is that you need these kinds of hacks while messing with old systems, building and stripping them, often in recovery type of situations. As said (same as the other person I saw reacting) details of what was most decidedly needed last time around escape me at the moment, but ide=reverse is the kind of hack that saves one hours of unscrewing computer cases and switching disks around while building stuff, making quick tests, doing recovery... If it must go for the greater architectural good, so be it, but it's the type of thing that's used specifically in the situations where you don't have stable, well arranged (or known!) setups to begin with. I might be off the deep end, but isn't this what Documentation/feature-removal-schedule.txt is for? Documentation/feature-removal-schedule.txt is for asking/discussing whether or not features should be removed? No, I don't think so. It seems to be a schedule of when to remove features. Rene. -- 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: ide=reverse do we still need this?
On 13-02-08 13:06, Rene Herman wrote: On 13-02-08 05:44, Greg KH wrote: While details escape me somewhat again at the monment, a few months ago I was playing around with a PCI Promise IDE controller and needed ide=reverse to save me from having to switch disks around to still have a bootable system. Or some such. Not too clear anymore, but I remember it saved the day. You couldn't just change the boot disk in grub? Or use an initramfs and /dev/disk/by-id/ to keep any future moves stable? No. The thing is that you need these kinds of hacks while messing with old systems, building and stripping them, often in recovery type of situations. As said (same as the other person I saw reacting) details of what was most decidedly needed last time around escape me at the moment, but ide=reverse is the kind of hack that saves one hours of unscrewing computer cases and switching disks around while building stuff, making quick tests, doing recovery... If it must go for the greater architectural good, so be it, but it's the type of thing that's used specifically in the situations where you don't have stable, well arranged (or known!) setups to begin with. Allow me to add that the demise of drivers/ide itself is an argument for just shooting the thing if it helps clean up the API. Next year when I'm messing with that Promise controller again, the machine might very well be running a kernel using PATA instead of IDE anyway... Rene. -- 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: "ide=reverse" do we still need this?
On 13-02-08 01:15, Greg KH wrote: I'm reworking the pci device list logic (we currently keep all PCI devices in 2 lists, which isn't the nicest, we should be able to get away with only 1 list.) The only bother I've found so far is the pci_get_device_reverse() function, it's used in 2 places, IDE and the calgary driver. I'm curious if we really still support the ide=reverse option? It's a config option that I don't think the distros still enable (SuSE does not). Is this still needed these days? In digging, we changed this option in 2.2.x from being called "pci=reverse" and no one else seems to miss it. Any thoughts? While details escape me somewhat again at the monment, a few months ago I was playing around with a PCI Promise IDE controller and needed ide=reverse to save me from having to switch disks around to still have a bootable system. Or some such. Not too clear anymore, but I remember it saved the day. Rene. -- 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: BTRFS partition usage...
On 13-02-08 00:42, Jan Engelhardt wrote: x86 MSDOS partition table layout starts counting with sector 1, which is (not so intuitively) starting at 0x7e00 (and there's no sector 0, probably for safety). Well, each ptable format with its own quirks. I haven't followed this thread, but in case it matters -- this sounds fairly confused. Not sure what you're saying, but the MSDOS partition table has its root table in the very first sector on the disk, at offset 0x1be = 0x200 - 4 * sizeof(struct partition) - 2 (that is, 4 entries at the end of that first sector, followed by a 2-byte signature). That 0x7e00 that you are speaking of sounds somewhat like the _memory_ address the BIOS loads that first sector to: 0x7c00. It then jumps there to start the ball rolling but 0x7c00 is not an on-disk reality or anything. MS-DOS partition tables are furthermore fully outside the actual partitions themselves and as such I believe not all together relevant to the issue? (as said, not following along though...) Rene -- 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: ide=reverse do we still need this?
On 13-02-08 01:15, Greg KH wrote: I'm reworking the pci device list logic (we currently keep all PCI devices in 2 lists, which isn't the nicest, we should be able to get away with only 1 list.) The only bother I've found so far is the pci_get_device_reverse() function, it's used in 2 places, IDE and the calgary driver. I'm curious if we really still support the ide=reverse option? It's a config option that I don't think the distros still enable (SuSE does not). Is this still needed these days? In digging, we changed this option in 2.2.x from being called pci=reverse and no one else seems to miss it. Any thoughts? While details escape me somewhat again at the monment, a few months ago I was playing around with a PCI Promise IDE controller and needed ide=reverse to save me from having to switch disks around to still have a bootable system. Or some such. Not too clear anymore, but I remember it saved the day. Rene. -- 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: BTRFS partition usage...
On 13-02-08 00:42, Jan Engelhardt wrote: x86 MSDOS partition table layout starts counting with sector 1, which is (not so intuitively) starting at 0x7e00 (and there's no sector 0, probably for safety). Well, each ptable format with its own quirks. I haven't followed this thread, but in case it matters -- this sounds fairly confused. Not sure what you're saying, but the MSDOS partition table has its root table in the very first sector on the disk, at offset 0x1be = 0x200 - 4 * sizeof(struct partition) - 2 (that is, 4 entries at the end of that first sector, followed by a 2-byte signature). That 0x7e00 that you are speaking of sounds somewhat like the _memory_ address the BIOS loads that first sector to: 0x7c00. It then jumps there to start the ball rolling but 0x7c00 is not an on-disk reality or anything. MS-DOS partition tables are furthermore fully outside the actual partitions themselves and as such I believe not all together relevant to the issue? (as said, not following along though...) Rene -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Allocate pnp resources dynamically via krealloc - Yet another Version
On 06-02-08 15:38, Thomas Renninger wrote: I expect on Rene's machine (might be something else, but this probably often happens), BIOS exports dma and IO ports. The irq seem to be missing and the driver does not use pnp_irq_valid, but pnp_irq. It No. Please note we're talking about ISAPnP, not PnPBIOS. No BIOS involved at all. Driver (sound/isa/cs423x/cs4236.c) furthermore does not use anything but the PnP layer itself. Start at snd_cs423x_pnpc_detect, which is the pnp .probe() method. I'll look into providing a more extensive answer and/or test whatever comes in later. Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Allocate pnp resources dynamically via krealloc - Yet another Version
On 06-02-08 15:38, Thomas Renninger wrote: I expect on Rene's machine (might be something else, but this probably often happens), BIOS exports dma and IO ports. The irq seem to be missing and the driver does not use pnp_irq_valid, but pnp_irq. It No. Please note we're talking about ISAPnP, not PnPBIOS. No BIOS involved at all. Driver (sound/isa/cs423x/cs4236.c) furthermore does not use anything but the PnP layer itself. Start at snd_cs423x_pnpc_detect, which is the pnp .probe() method. I'll look into providing a more extensive answer and/or test whatever comes in later. Rene. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Allocate pnp resources dynamically via krealloc - working version - Addon patch 3
On 28-01-08 20:12, Thomas Renninger wrote:
This was more a step backward, hopefully this one (on top), gets the
area bugfree?
I'm afraid not. Next oops in pnp_check_port(). The attached lets it get past
that point but _then_ things fall apart a little bit further on again which
seems to mean it's something a bit more fundamental. Should pnp_check_* even
be called without any initialised resources?
Without the attached:
===
pnp: the driver 'cs4236_isapnp' has been registered
cs4236_isapnp 01:01.00: driver attached
cs4236_isapnp 01:01.02: driver attached
cs4236_isapnp 01:01.03: driver attached
BUG: unable to handle kernel NULL pointer dereference at virtual address
000c
printing eip: c10e4365 *pde =
Oops: [#1] PREEMPT
Modules linked in: snd_cs4236 snd_opl3_lib snd_hwdep snd_cs4236_lib
snd_mpu401_uart snd_rawmidi snd_seq_device snd_cs4231_lib snd_pcm snd_timer
snd soundcore s
nd_page_alloc nfsd lockd nfs_acl sunrpc exportfs
Pid: 1350, comm: modprobe Not tainted (2.6.24-local #6)
EIP: 0060:[] EFLAGS: 00010246 CPU: 0
EIP is at pnp_check_port+0x15/0x125
EAX: ef8f5800 EBX: ECX: EDX:
ESI: ef8f5800 EDI: EBP: ef8f5800 ESP: e447edec
DS: 007b ES: 007b FS: GS: 0033 SS: 0068
Process modprobe (pid: 1350, ti=e447e000 task=ed35f4c0 task.ti=e447e000)
Stack: e447d900 c108ab97 ef8fe100 ef8f5800 ef82ae40 c10e5295
0534 0537 4101 efa4e360 c108b88b e4462180 ef8fe100
ef8f5800 c10e5426 0001 ef8f5964
Call Trace:
[] sysfs_find_dirent+0x13/0x23
[] pnp_assign_port+0xe5/0x104
[] sysfs_create_link+0xd0/0x111
[] pnp_assign_resources+0x172/0x23a
[] pnp_auto_config_dev+0x67/0xa6
[] pnp_request_card_device+0x9b/0xbe
[] pnp_activate_dev+0x13/0x3c
[] snd_cs423x_pnpc_detect+0xe4/0x35f [snd_cs4236]
[] pnp_alloc+0xe/0x25
[] card_probe+0xba/0x107
[] pnp_register_card_driver+0xa3/0xb3
[] alsa_card_cs423x_init+0x2f/0x4f [snd_cs4236]
[] sys_init_module+0x1379/0x149b
[] unmap_region+0xe5/0x100
[] syscall_call+0x7/0xb
===
Code: ac 29 c1 75 a7 b8 01 00 00 00 eb 02 31 c0 83 c4 0c 5b 5e 5f 5d c3 55
89 c5 57 56 53 6b da 1c 83 ec 0c 89 14 24 03 98 64 01 00 00 43 0c 00 00
00 30 0
f 85 f2 00 00 00 83 b8 54 01 00 00 00 75
EIP: [] pnp_check_port+0x15/0x125 SS:ESP 0068:e447edec
---[ end trace 149e6ce75dd3870f ]---
===
With the attached:
===
pnp: the driver 'cs4236_isapnp' has been registered
cs4236_isapnp 01:01.00: driver attached
cs4236_isapnp 01:01.02: driver attached
cs4236_isapnp 01:01.03: driver attached
pnp: Port allocate: ed366400 - ed369500; Allocated: 448 bytes, size
ofstruct: 28 - allocated ports: 8
pnp: Dma allocate: ed276a80 - ed2776c0; Allocated: 112 bytes, size ofstruct:
28 - allocated dmas: 2
cs4236_isapnp 01:01.00: activated
BUG: unable to handle kernel NULL pointer dereference at virtual address
printing eip: f0a4b5a8 *pde =
Oops: [#1] PREEMPT
Modules linked in: snd_cs4236 snd_opl3_lib snd_hwdep snd_cs4236_lib
snd_mpu401_uart snd_rawmidi snd_seq_device snd_cs4231_lib snd_pcm snd_timer
snd soundcore snd_page_alloc nfsd lockd nfs_acl sunrpc exportfs
Pid: 1348, comm: modprobe Not tainted (2.6.24-local #9)
EIP: 0060:[] EFLAGS: 00010202 CPU: 0
EIP is at snd_cs423x_pnpc_detect+0x133/0x35f [snd_cs4236]
EAX: EBX: ef8f5800 ECX: 0220 EDX: 0001
ESI: EDI: 0534 EBP: ed338200 ESP: ed3cfe90
DS: 007b ES: 007b FS: GS: 0033 SS: 0068
Process modprobe (pid: 1348, ti=ed3cf000 task=ed2c79f0 task.ti=ed3cf000)
Stack: 0286 0001 f0a4d780 c10e330d c12b7c6c ef8f5e00 ed26fe80 ed3383bc
ef8f5e00 ed26fe80 f0a4e0a4 0003 c10e3652 f0a4d740 ef8f5600 f0a4d740
efa4f514 f0a8aa4c c10e3b75 0001 f0a4e440 f08de02f ed338fc4
Call Trace:
[] pnp_alloc+0xe/0x25
[] card_probe+0xba/0x107
[] pnp_register_card_driver+0xa3/0xb3
[] alsa_card_cs423x_init+0x2f/0x4f [snd_cs4236]
[] sys_init_module+0x1379/0x149b
[] unmap_region+0xe5/0x100
[] syscall_call+0x7/0xb
===
Code: d6 a4 f0 7e 10 8b 83 64 01 00 00 8b 40 1c 89 04 b5 60 d6 a4 f0 8b 83
64 01 00 00 8b 48 38 89 0c b5 40 d6 a4 f0 8b 83 7c 01 00 00 <8b> 00 89 04 b5
20 d6 a4 f0 8b 83 74 01 00 00 8b 00 89 04 b5 e0
EIP: [] snd_cs423x_pnpc_detect+0x133/0x35f [snd_cs4236] SS:ESP
0068:ed3cfe90
---[ end trace 9f2b1188efb740f7 ]---
===
For reference:
# cat /sys/bus/pnp/devices/01\:01.00/options
Dependent: 01 - Priority preferred
port 0x534-0x534, align 0x3, size 0x4, 16-bit address decoding
port 0x388-0x388, align 0x7, size 0x4, 16-bit address decoding
port 0x220-0x220, align 0x1f, size 0x10, 16-bit address decoding
irq 5 High-Edge
dma 1 8-bit master byte-count type-F
dma 0 8-bit master byte-count type-F
Rene.
diff --git a/drivers/pnp/resource.c b/drivers/pnp/resource.c
index f1fdd96..21719e5 100644
--- a/drivers/pnp/resource.c
+++ b/drivers/pnp/resource.c
@@ -219,13 +219,14 @@ int
Re: [PATCH] Allocate pnp resources dynamically via krealloc - working version - Addon patch 1
On 28-01-08 17:04, Thomas Renninger wrote:
Can you try these two "on top" patches pls.
Thought I could, but my machine begs to differ...
===
pnp: the driver 'cs4236_isapnp' has been registered
cs4236_isapnp 01:01.00: driver attached
cs4236_isapnp 01:01.02: driver attached
cs4236_isapnp 01:01.03: driver attached
BUG: unable to handle kernel NULL pointer dereference at virtual address
000f
printing eip: c10e5136 *pde =
Oops: [#1] PREEMPT
Modules linked in: snd_cs4236 snd_opl3_lib snd_hwdep snd_cs4236_lib
snd_mpu401_uart snd_rawmidi snd_seq_device snd_cs4231_lib snd_pcm snd_timer
snd_page_alloc snd soundcore nfsd lockd nfs_acl sunrpc exportfs
Pid: 1370, comm: modprobe Not tainted (2.6.24-local #5)
EIP: 0060:[] EFLAGS: 00010246 CPU: 0
EIP is at pnp_assign_port+0x1d/0xd5
EAX: EBX: ECX: EDX: 0001
ESI: ef8fe100 EDI: ef8f5800 EBP: ESP: ed3b4e08
DS: 007b ES: 007b FS: GS: 0033 SS: 0068
Process modprobe (pid: 1370, ti=ed3b4000 task=ed35c000 task.ti=ed3b4000)
Stack: ed3b4e34 c108ac94 ed3b4e34 ed3c1b10 efa4e360 c108b88b ef8fe100
ef8f5800 ef82ee40 c10e5360 0001 ef8f5964
ef805ea0 ef8f5800 ef863c80 0001 ed373400
Call Trace:
[] sysfs_addrm_start+0x36/0x81
[] sysfs_create_link+0xd0/0x111
[] pnp_assign_resources+0x172/0x23a
[] pnp_auto_config_dev+0x67/0xa6
[] pnp_request_card_device+0x9b/0xbe
[] pnp_activate_dev+0x13/0x3a
[] snd_cs423x_pnpc_detect+0xe4/0x35f [snd_cs4236]
[] pnp_alloc+0xe/0x25
[] card_probe+0xba/0x107
[] pnp_register_card_driver+0xa3/0xb3
[] alsa_card_cs423x_init+0x2f/0x4f [snd_cs4236]
[] sys_init_module+0x1379/0x149b
[] unmap_region+0xe5/0x100
[] syscall_call+0x7/0xb
===
Code: ba 01 00 00 00 83 c4 1c 89 d0 5b 5e 5f c3 55 89 cd 57 89 c7 56 89 d6
ba 01 00 00 00 53 6b d9 1c 83 ec 1c 89 d8 03 87 64 01 00 00 40 0f 40 0f
84 a4 00 00 00 8b 00 8b 97 64 01 00 00 0f b6 4e
EIP: [] pnp_assign_port+0x1d/0xd5 SS:ESP 0068:ed3b4e08
---[ end trace d756fac577a9260d ]---
Rene.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Allocate pnp resources dynamically via krealloc - working version
On 28-01-08 15:21, Thomas Renninger wrote: I think I know what is going on. While pnpbios and pnpacpi theoretically do not have limits, isapnp has spec restrictions (AFAIK, I have not read this up, but taken over from previous implementation...). Therefore in isapnp I wanted to stay with: #define PNP_MAX_PORT8 #define PNP_MAX_MEM 4 #define PNP_MAX_IRQ 2 #define PNP_MAX_DMA 2 but I have forgotten to malloc one portion for each at init time, or even better one portion as soon as one is needed. Yup. As said, isapnp is more or less untested, thanks a lot for trying out. I will send an updated version soon. I"m not sure of the flow of things by the way but if it makes better/nicer code to just pretend that ISAPnP is also unlimited then I'd say to simply do so. ISAPnP is getting obsolete anyway, not anything to optimise for... Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Allocate pnp resources dynamically via krealloc - working version - Addon patch 1
On 28-01-08 17:04, Thomas Renninger wrote:
Can you try these two on top patches pls.
Thought I could, but my machine begs to differ...
===
pnp: the driver 'cs4236_isapnp' has been registered
cs4236_isapnp 01:01.00: driver attached
cs4236_isapnp 01:01.02: driver attached
cs4236_isapnp 01:01.03: driver attached
BUG: unable to handle kernel NULL pointer dereference at virtual address
000f
printing eip: c10e5136 *pde =
Oops: [#1] PREEMPT
Modules linked in: snd_cs4236 snd_opl3_lib snd_hwdep snd_cs4236_lib
snd_mpu401_uart snd_rawmidi snd_seq_device snd_cs4231_lib snd_pcm snd_timer
snd_page_alloc snd soundcore nfsd lockd nfs_acl sunrpc exportfs
Pid: 1370, comm: modprobe Not tainted (2.6.24-local #5)
EIP: 0060:[c10e5136] EFLAGS: 00010246 CPU: 0
EIP is at pnp_assign_port+0x1d/0xd5
EAX: EBX: ECX: EDX: 0001
ESI: ef8fe100 EDI: ef8f5800 EBP: ESP: ed3b4e08
DS: 007b ES: 007b FS: GS: 0033 SS: 0068
Process modprobe (pid: 1370, ti=ed3b4000 task=ed35c000 task.ti=ed3b4000)
Stack: ed3b4e34 c108ac94 ed3b4e34 ed3c1b10 efa4e360 c108b88b ef8fe100
ef8f5800 ef82ee40 c10e5360 0001 ef8f5964
ef805ea0 ef8f5800 ef863c80 0001 ed373400
Call Trace:
[c108ac94] sysfs_addrm_start+0x36/0x81
[c108b88b] sysfs_create_link+0xd0/0x111
[c10e5360] pnp_assign_resources+0x172/0x23a
[c10e548f] pnp_auto_config_dev+0x67/0xa6
[c10e373a] pnp_request_card_device+0x9b/0xbe
[c10e54e1] pnp_activate_dev+0x13/0x3a
[f0a4b559] snd_cs423x_pnpc_detect+0xe4/0x35f [snd_cs4236]
[c10e330d] pnp_alloc+0xe/0x25
[c10e3652] card_probe+0xba/0x107
[c10e3b75] pnp_register_card_driver+0xa3/0xb3
[f08de02f] alsa_card_cs423x_init+0x2f/0x4f [snd_cs4236]
[c103258a] sys_init_module+0x1379/0x149b
[c104773a] unmap_region+0xe5/0x100
[c1003d62] syscall_call+0x7/0xb
===
Code: ba 01 00 00 00 83 c4 1c 89 d0 5b 5e 5f c3 55 89 cd 57 89 c7 56 89 d6
ba 01 00 00 00 53 6b d9 1c 83 ec 1c 89 d8 03 87 64 01 00 00 f6 40 0f 40 0f
84 a4 00 00 00 8b 00 8b 97 64 01 00 00 0f b6 4e
EIP: [c10e5136] pnp_assign_port+0x1d/0xd5 SS:ESP 0068:ed3b4e08
---[ end trace d756fac577a9260d ]---
Rene.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Allocate pnp resources dynamically via krealloc - working version - Addon patch 3
On 28-01-08 20:12, Thomas Renninger wrote:
This was more a step backward, hopefully this one (on top), gets the
area bugfree?
I'm afraid not. Next oops in pnp_check_port(). The attached lets it get past
that point but _then_ things fall apart a little bit further on again which
seems to mean it's something a bit more fundamental. Should pnp_check_* even
be called without any initialised resources?
Without the attached:
===
pnp: the driver 'cs4236_isapnp' has been registered
cs4236_isapnp 01:01.00: driver attached
cs4236_isapnp 01:01.02: driver attached
cs4236_isapnp 01:01.03: driver attached
BUG: unable to handle kernel NULL pointer dereference at virtual address
000c
printing eip: c10e4365 *pde =
Oops: [#1] PREEMPT
Modules linked in: snd_cs4236 snd_opl3_lib snd_hwdep snd_cs4236_lib
snd_mpu401_uart snd_rawmidi snd_seq_device snd_cs4231_lib snd_pcm snd_timer
snd soundcore s
nd_page_alloc nfsd lockd nfs_acl sunrpc exportfs
Pid: 1350, comm: modprobe Not tainted (2.6.24-local #6)
EIP: 0060:[c10e4365] EFLAGS: 00010246 CPU: 0
EIP is at pnp_check_port+0x15/0x125
EAX: ef8f5800 EBX: ECX: EDX:
ESI: ef8f5800 EDI: EBP: ef8f5800 ESP: e447edec
DS: 007b ES: 007b FS: GS: 0033 SS: 0068
Process modprobe (pid: 1350, ti=e447e000 task=ed35f4c0 task.ti=e447e000)
Stack: e447d900 c108ab97 ef8fe100 ef8f5800 ef82ae40 c10e5295
0534 0537 4101 efa4e360 c108b88b e4462180 ef8fe100
ef8f5800 c10e5426 0001 ef8f5964
Call Trace:
[c108ab97] sysfs_find_dirent+0x13/0x23
[c10e5295] pnp_assign_port+0xe5/0x104
[c108b88b] sysfs_create_link+0xd0/0x111
[c10e5426] pnp_assign_resources+0x172/0x23a
[c10e] pnp_auto_config_dev+0x67/0xa6
[c10e373a] pnp_request_card_device+0x9b/0xbe
[c10e55a7] pnp_activate_dev+0x13/0x3c
[f0a4b559] snd_cs423x_pnpc_detect+0xe4/0x35f [snd_cs4236]
[c10e330d] pnp_alloc+0xe/0x25
[c10e3652] card_probe+0xba/0x107
[c10e3b75] pnp_register_card_driver+0xa3/0xb3
[f08de02f] alsa_card_cs423x_init+0x2f/0x4f [snd_cs4236]
[c103258a] sys_init_module+0x1379/0x149b
[c104773a] unmap_region+0xe5/0x100
[c1003d62] syscall_call+0x7/0xb
===
Code: ac 29 c1 75 a7 b8 01 00 00 00 eb 02 31 c0 83 c4 0c 5b 5e 5f 5d c3 55
89 c5 57 56 53 6b da 1c 83 ec 0c 89 14 24 03 98 64 01 00 00 f7 43 0c 00 00
00 30 0
f 85 f2 00 00 00 83 b8 54 01 00 00 00 75
EIP: [c10e4365] pnp_check_port+0x15/0x125 SS:ESP 0068:e447edec
---[ end trace 149e6ce75dd3870f ]---
===
With the attached:
===
pnp: the driver 'cs4236_isapnp' has been registered
cs4236_isapnp 01:01.00: driver attached
cs4236_isapnp 01:01.02: driver attached
cs4236_isapnp 01:01.03: driver attached
pnp: Port allocate: ed366400 - ed369500; Allocated: 448 bytes, size
ofstruct: 28 - allocated ports: 8
pnp: Dma allocate: ed276a80 - ed2776c0; Allocated: 112 bytes, size ofstruct:
28 - allocated dmas: 2
cs4236_isapnp 01:01.00: activated
BUG: unable to handle kernel NULL pointer dereference at virtual address
printing eip: f0a4b5a8 *pde =
Oops: [#1] PREEMPT
Modules linked in: snd_cs4236 snd_opl3_lib snd_hwdep snd_cs4236_lib
snd_mpu401_uart snd_rawmidi snd_seq_device snd_cs4231_lib snd_pcm snd_timer
snd soundcore snd_page_alloc nfsd lockd nfs_acl sunrpc exportfs
Pid: 1348, comm: modprobe Not tainted (2.6.24-local #9)
EIP: 0060:[f0a4b5a8] EFLAGS: 00010202 CPU: 0
EIP is at snd_cs423x_pnpc_detect+0x133/0x35f [snd_cs4236]
EAX: EBX: ef8f5800 ECX: 0220 EDX: 0001
ESI: EDI: 0534 EBP: ed338200 ESP: ed3cfe90
DS: 007b ES: 007b FS: GS: 0033 SS: 0068
Process modprobe (pid: 1348, ti=ed3cf000 task=ed2c79f0 task.ti=ed3cf000)
Stack: 0286 0001 f0a4d780 c10e330d c12b7c6c ef8f5e00 ed26fe80 ed3383bc
ef8f5e00 ed26fe80 f0a4e0a4 0003 c10e3652 f0a4d740 ef8f5600 f0a4d740
efa4f514 f0a8aa4c c10e3b75 0001 f0a4e440 f08de02f ed338fc4
Call Trace:
[c10e330d] pnp_alloc+0xe/0x25
[c10e3652] card_probe+0xba/0x107
[c10e3b75] pnp_register_card_driver+0xa3/0xb3
[f08de02f] alsa_card_cs423x_init+0x2f/0x4f [snd_cs4236]
[c103258a] sys_init_module+0x1379/0x149b
[c104773a] unmap_region+0xe5/0x100
[c1003d62] syscall_call+0x7/0xb
===
Code: d6 a4 f0 7e 10 8b 83 64 01 00 00 8b 40 1c 89 04 b5 60 d6 a4 f0 8b 83
64 01 00 00 8b 48 38 89 0c b5 40 d6 a4 f0 8b 83 7c 01 00 00 8b 00 89 04 b5
20 d6 a4 f0 8b 83 74 01 00 00 8b 00 89 04 b5 e0
EIP: [f0a4b5a8] snd_cs423x_pnpc_detect+0x133/0x35f [snd_cs4236] SS:ESP
0068:ed3cfe90
---[ end trace 9f2b1188efb740f7 ]---
===
For reference:
# cat /sys/bus/pnp/devices/01\:01.00/options
Dependent: 01 - Priority preferred
port 0x534-0x534, align 0x3, size 0x4, 16-bit address decoding
port 0x388-0x388, align 0x7, size 0x4, 16-bit address decoding
port 0x220-0x220, align 0x1f, size 0x10, 16-bit address decoding
irq 5 High-Edge
dma 1 8-bit master byte-count type-F
dma 0 8-bit master
Re: [PATCH] Allocate pnp resources dynamically via krealloc - working version
On 28-01-08 15:21, Thomas Renninger wrote: I think I know what is going on. While pnpbios and pnpacpi theoretically do not have limits, isapnp has spec restrictions (AFAIK, I have not read this up, but taken over from previous implementation...). Therefore in isapnp I wanted to stay with: #define PNP_MAX_PORT8 #define PNP_MAX_MEM 4 #define PNP_MAX_IRQ 2 #define PNP_MAX_DMA 2 but I have forgotten to malloc one portion for each at init time, or even better one portion as soon as one is needed. Yup. As said, isapnp is more or less untested, thanks a lot for trying out. I will send an updated version soon. Im not sure of the flow of things by the way but if it makes better/nicer code to just pretend that ISAPnP is also unlimited then I'd say to simply do so. ISAPnP is getting obsolete anyway, not anything to optimise for... Rene. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Allocate pnp resources dynamically via krealloc - working version
On 23-01-08 18:38, Thomas Renninger wrote: isapnp is totally untested. Also the sysfs is rather untested. If nobody beats me to it I'll debug this myself later on, but as a quick heads up: pnp: the driver 'cs4236_isapnp' has been registered cs4236_isapnp 01:01.00: driver attached cs4236_isapnp 01:01.02: driver attached cs4236_isapnp 01:01.03: driver attached pnp: Port resource 0 not allocated, cannot assign value pnp: Port resource 1 not allocated, cannot assign value pnp: Port resource 2 not allocated, cannot assign value pnp: Irq resource 0 not allocated, cannot assign value pnp: DMA resource 0 not allocated, cannot assign value pnp: DMA resource 1 not allocated, cannot assign value BUG: unable to handle kernel NULL pointer dereference at virtual address 000c printing eip: c10e76d9 *pde = Oops: [#1] PREEMPT Modules linked in: snd_cs4236 snd_opl3_lib snd_hwdep snd_cs4236_lib snd_mpu401_uart snd_rawmidi snd_seq_device snd_cs4231_lib snd_pcm snd_timer snd_page_alloc snd soundcore nfsd lockd nfs_acl sunrpc exportfs Pid: 1353, comm: modprobe Not tainted (2.6.24-local #2) EIP: 0060:[] EFLAGS: 00010246 CPU: 0 EIP is at isapnp_set_resources+0x4d/0x132 EAX: EBX: ECX: e3c8f000 EDX: ESI: EDI: ef8f5964 EBP: ef8f5800 ESP: e3c8fe5c DS: 007b ES: 007b FS: GS: 0033 SS: 0068 Process modprobe (pid: 1353, ti=e3c8f000 task=ed2c2f90 task.ti=e3c8f000) Stack: ef8f5800 ef8f5888 f0a4e0a4 ed349000 c10e48c8 c10e373a f0a4e0c0 ef8f5800 ef8f5800 c10e5101 ef8f5800 f0a4b559 0286 0001 f0a4d780 c10e330d c12b7c6c ef8f5e00 ed37f140 ed3491bc ef8f5e00 ed37f140 f0a4e0a4 Call Trace: [] pnp_start_dev+0x55/0x9e [] pnp_request_card_device+0x9b/0xbe [] pnp_activate_dev+0x23/0x39 [] snd_cs423x_pnpc_detect+0xe4/0x35f [snd_cs4236] [] pnp_alloc+0xe/0x25 [] card_probe+0xba/0x107 [] pnp_register_card_driver+0xa3/0xb3 [] alsa_card_cs423x_init+0x2f/0x4f [snd_cs4236] [] sys_init_module+0x1379/0x149b [] unmap_region+0xe5/0x100 [] syscall_call+0x7/0xb === Code: ff ff ff c7 85 54 01 00 00 01 00 00 00 eb 18 0f b7 12 8d 44 1b 60 43 83 c6 1c 0f b6 c0 e8 ce fd ff ff 83 fb 08 74 13 89 f2 03 17 <8b> 42 0c 25 00 01 00 20 3d 00 01 00 00 74 d5 31 db 31 f6 eb 25 EIP: [] isapnp_set_resources+0x4d/0x132 SS:ESP 0068:e3c8fe5c ---[ end trace f836fd70d1d20199 ]--- Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Allocate pnp resources dynamically via krealloc - working version
On 23-01-08 18:38, Thomas Renninger wrote: isapnp is totally untested. Also the sysfs is rather untested. If nobody beats me to it I'll debug this myself later on, but as a quick heads up: pnp: the driver 'cs4236_isapnp' has been registered cs4236_isapnp 01:01.00: driver attached cs4236_isapnp 01:01.02: driver attached cs4236_isapnp 01:01.03: driver attached pnp: Port resource 0 not allocated, cannot assign value pnp: Port resource 1 not allocated, cannot assign value pnp: Port resource 2 not allocated, cannot assign value pnp: Irq resource 0 not allocated, cannot assign value pnp: DMA resource 0 not allocated, cannot assign value pnp: DMA resource 1 not allocated, cannot assign value BUG: unable to handle kernel NULL pointer dereference at virtual address 000c printing eip: c10e76d9 *pde = Oops: [#1] PREEMPT Modules linked in: snd_cs4236 snd_opl3_lib snd_hwdep snd_cs4236_lib snd_mpu401_uart snd_rawmidi snd_seq_device snd_cs4231_lib snd_pcm snd_timer snd_page_alloc snd soundcore nfsd lockd nfs_acl sunrpc exportfs Pid: 1353, comm: modprobe Not tainted (2.6.24-local #2) EIP: 0060:[c10e76d9] EFLAGS: 00010246 CPU: 0 EIP is at isapnp_set_resources+0x4d/0x132 EAX: EBX: ECX: e3c8f000 EDX: ESI: EDI: ef8f5964 EBP: ef8f5800 ESP: e3c8fe5c DS: 007b ES: 007b FS: GS: 0033 SS: 0068 Process modprobe (pid: 1353, ti=e3c8f000 task=ed2c2f90 task.ti=e3c8f000) Stack: ef8f5800 ef8f5888 f0a4e0a4 ed349000 c10e48c8 c10e373a f0a4e0c0 ef8f5800 ef8f5800 c10e5101 ef8f5800 f0a4b559 0286 0001 f0a4d780 c10e330d c12b7c6c ef8f5e00 ed37f140 ed3491bc ef8f5e00 ed37f140 f0a4e0a4 Call Trace: [c10e48c8] pnp_start_dev+0x55/0x9e [c10e373a] pnp_request_card_device+0x9b/0xbe [c10e5101] pnp_activate_dev+0x23/0x39 [f0a4b559] snd_cs423x_pnpc_detect+0xe4/0x35f [snd_cs4236] [c10e330d] pnp_alloc+0xe/0x25 [c10e3652] card_probe+0xba/0x107 [c10e3b75] pnp_register_card_driver+0xa3/0xb3 [f08de02f] alsa_card_cs423x_init+0x2f/0x4f [snd_cs4236] [c103258a] sys_init_module+0x1379/0x149b [c104773a] unmap_region+0xe5/0x100 [c1003d62] syscall_call+0x7/0xb === Code: ff ff ff c7 85 54 01 00 00 01 00 00 00 eb 18 0f b7 12 8d 44 1b 60 43 83 c6 1c 0f b6 c0 e8 ce fd ff ff 83 fb 08 74 13 89 f2 03 17 8b 42 0c 25 00 01 00 20 3d 00 01 00 00 74 d5 31 db 31 f6 eb 25 EIP: [c10e76d9] isapnp_set_resources+0x4d/0x132 SS:ESP 0068:e3c8fe5c ---[ end trace f836fd70d1d20199 ]--- Rene. -- 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: Question about set_intr_gate_ist()
On 21-01-08 07:23, jidong xiao wrote: I know there is set_intr_gate(n,addr) which is used to insert an interrupt gate in the n th IDT entry. But I don't know what the usage of set_intr_gate_ist()? The same, while setting the "Interrupt STack" field of the descriptor to "ist". This field is a 64-bit only field, implementing a hardware stack switch. Look for it in the AMD64 docs. Rene. -- 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: Question about set_intr_gate_ist()
On 21-01-08 07:23, jidong xiao wrote: I know there is set_intr_gate(n,addr) which is used to insert an interrupt gate in the n th IDT entry. But I don't know what the usage of set_intr_gate_ist()? The same, while setting the Interrupt STack field of the descriptor to ist. This field is a 64-bit only field, implementing a hardware stack switch. Look for it in the AMD64 docs. Rene. -- 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: [linux-kernel] Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On 18-01-08 14:37, David Newall wrote: The problem is that _p is widely used for non-ISA devices. Yes, we know, it's being fixed. Piss off. Rene. -- 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: [linux-kernel] Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On 18-01-08 14:37, David Newall wrote: The problem is that _p is widely used for non-ISA devices. Yes, we know, it's being fixed. Piss off. Rene. -- 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: [linux-kernel] Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On 17-01-08 22:58, David Newall wrote: Rene Herman wrote: Over the course of a 100 messages or so in this thread it's been determined that the best course of action is to keep the out for ISA and replace it with udelay() for chipset logic. Now go away. Rather than this incredible rudeness, why don't you direct your energy towards convincing Alan of this. He's the hold-out. No he isn't and that's why I'm rude -- everything needs to be repeated over and over and over again. Read the thread(s). You didn't limit your reply to chipset logic and Alan even already submitted patches to isolate the delay for the chipset logic (PIC and PIT that is) where the expectation is that a simple udelay() will suffice. We've already talked about ISA bus speed, and how it's not in a sane sense portably determinable, we've already talked about kernel parameters, about udelay and it's usefulness in early boot, about how your rude "Junk I/O" is exactly what is needed for some ISA devices and so on... In fact, we're blue in the face from talking about it. So say something useful or go away. Rene -- 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: [linux-kernel] Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On 17-01-08 14:36, David Newall wrote: In the early days of clone PCs, as you know but perhaps many on this list might not I'm so incredibly sick of this fucking thread. We've had enough legacy farts coming out of the woodwork advertising their own massive experience and cluelessness by now. Both hpa and alan are in this thread and everyone else can be ignored on the issue. Over the course of a 100 messages or so in this thread it's been determined that the best course of action is to keep the out for ISA and replace it with udelay() for chipset logic. Now go away. Rene. -- 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: [linux-kernel] Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On 17-01-08 14:36, David Newall wrote: In the early days of clone PCs, as you know but perhaps many on this list might not I'm so incredibly sick of this fucking thread. We've had enough legacy farts coming out of the woodwork advertising their own massive experience and cluelessness by now. Both hpa and alan are in this thread and everyone else can be ignored on the issue. Over the course of a 100 messages or so in this thread it's been determined that the best course of action is to keep the out for ISA and replace it with udelay() for chipset logic. Now go away. Rene. -- 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: [linux-kernel] Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On 17-01-08 22:58, David Newall wrote: Rene Herman wrote: Over the course of a 100 messages or so in this thread it's been determined that the best course of action is to keep the out for ISA and replace it with udelay() for chipset logic. Now go away. Rather than this incredible rudeness, why don't you direct your energy towards convincing Alan of this. He's the hold-out. No he isn't and that's why I'm rude -- everything needs to be repeated over and over and over again. Read the thread(s). You didn't limit your reply to chipset logic and Alan even already submitted patches to isolate the delay for the chipset logic (PIC and PIT that is) where the expectation is that a simple udelay() will suffice. We've already talked about ISA bus speed, and how it's not in a sane sense portably determinable, we've already talked about kernel parameters, about udelay and it's usefulness in early boot, about how your rude Junk I/O is exactly what is needed for some ISA devices and so on... In fact, we're blue in the face from talking about it. So say something useful or go away. Rene -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/2] 8250_pnp: register x86 COM ports at the conventional ttyS names
On 16-01-08 21:42, H. Peter Anvin wrote: Bodo Eggert wrote: BTW1: These addresses may be used to detect ports on non-standard addresses, but unfortunately they don't tell the IRQ. BTW2: When I submitted a patch using the BIOS data area, I was told that it might not exist on systems booting from non-PC firmware. This claim was not yet backed with any knowledge, nor did anybody suggest a way to detect this situation. This is, of course, true. It doesn't exactly help that some (most?) non-PC firmware at least mimic the BIOS data area. In this particular case, there is some minor sanity-checking that can be done: the values should be nonzero and aligned 8. The number of places expected to contain something sensible should I believe first be verified at 0x410 -- the equipment word. Bits 11-9 (0x0e00) should be the number of serial ports, 0 to 4 (so 5-7 is also a sanity check) and if BIOSes can be expected to zero out the non-used base-addresses (at 0x400, 0x402, 0x404, 0x406) that's another sanity check. Don't know if they can though... Rene. -- 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: -mm: pnp-do-not-stop-start-devices-in-suspend-resume-path.patch breaks resuming isapnp cards
On 16-01-08 18:46, Bjorn Helgaas wrote: On Tuesday 15 January 2008 12:51:35 am Jaroslav Kysela wrote: Ok, something to explain. These flags exists to allow drivers to manually configure (override) PnP resources at init time - we know - for example in ALSA - that some combinations simply does not work for all soundcards. The DISABLE flags simply tells core PnP layer - driver will handle resource allocation itself, don't do anything, just disable hw physically and do not change (allocate) any resources. Value 0x03 is valid in this semantics. It looks like sound drivers use PNP_DRIVER_RES_DISABLE to say "ignore what PNP tells us about resource usage and we'll just use the compiled- in or command-line-specified resources". The main reason to do that would be to work around BIOS defects or to work around deficiencies in the Linux PNP infrastructure (e.g., maybe we erroneously place another device on top of the sound card or something). I'm just suspicious because PNP_DRIVER_RES_DISABLE is only used in sound drivers. If it's to work around BIOS defects, why wouldn't other PNP drivers need it sometimes, too? And wouldn't it be better to use PNP quirks for BIOS workarounds? Yes. The manual resource setting was recently removed from the ALSA drivers and I'd expect this can now go as a package-deal. Unfortunately, suspend / resume complicates things a bit, but PnP core can handle DO_NOT_CHANGE flag. But it will just mean - _preserve_ resource allocation from last suspend state for this device and enable hw physically before calling resume() callback. When resuming, wouldn't we *always* want to preserve the resource allocation from the last suspend, regardless of whether PNP_DRIVER_RES_DO_NOT_CHANGE is specified? Yes. Linux PNP definitely has issues with suspend/resume, and I suspect this is one of them. Rene. -- 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: pnpacpi : exceeded the max number of IO resources
On 16-01-08 09:00, Rene Herman wrote: On 16-01-08 06:55, Dave Young wrote: I noticed the port number changed to 40 in 2.6.24-rc8, but it's not enough for me still. Yes, that's known. In .23 even more were (silently) ignored though. Since .24-rc8 you should at least get just 1 warning (per resource type) Assuming, that is, that Linus would've applied Len's trivial fix here: http://lkml.org/lkml/2008/1/14/251 and if all's well .25 should kill the static limit completely. Rene. -- 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: pnpacpi : exceeded the max number of IO resources
On 16-01-08 06:55, Dave Young wrote: I noticed the port number changed to 40 in 2.6.24-rc8, but it's not enough for me still. Yes, that's known. In .23 even more were (silently) ignored though. Since .24-rc8 you should at least get just 1 warning (per resource type) and if all's well .25 should kill the static limit completely. Rene. -- 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: pnpacpi : exceeded the max number of IO resources
On 16-01-08 06:55, Dave Young wrote: I noticed the port number changed to 40 in 2.6.24-rc8, but it's not enough for me still. Yes, that's known. In .23 even more were (silently) ignored though. Since .24-rc8 you should at least get just 1 warning (per resource type) and if all's well .25 should kill the static limit completely. Rene. -- 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: pnpacpi : exceeded the max number of IO resources
On 16-01-08 09:00, Rene Herman wrote: On 16-01-08 06:55, Dave Young wrote: I noticed the port number changed to 40 in 2.6.24-rc8, but it's not enough for me still. Yes, that's known. In .23 even more were (silently) ignored though. Since .24-rc8 you should at least get just 1 warning (per resource type) Assuming, that is, that Linus would've applied Len's trivial fix here: http://lkml.org/lkml/2008/1/14/251 and if all's well .25 should kill the static limit completely. Rene. -- 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: -mm: pnp-do-not-stop-start-devices-in-suspend-resume-path.patch breaks resuming isapnp cards
On 16-01-08 18:46, Bjorn Helgaas wrote: On Tuesday 15 January 2008 12:51:35 am Jaroslav Kysela wrote: Ok, something to explain. These flags exists to allow drivers to manually configure (override) PnP resources at init time - we know - for example in ALSA - that some combinations simply does not work for all soundcards. The DISABLE flags simply tells core PnP layer - driver will handle resource allocation itself, don't do anything, just disable hw physically and do not change (allocate) any resources. Value 0x03 is valid in this semantics. It looks like sound drivers use PNP_DRIVER_RES_DISABLE to say ignore what PNP tells us about resource usage and we'll just use the compiled- in or command-line-specified resources. The main reason to do that would be to work around BIOS defects or to work around deficiencies in the Linux PNP infrastructure (e.g., maybe we erroneously place another device on top of the sound card or something). I'm just suspicious because PNP_DRIVER_RES_DISABLE is only used in sound drivers. If it's to work around BIOS defects, why wouldn't other PNP drivers need it sometimes, too? And wouldn't it be better to use PNP quirks for BIOS workarounds? Yes. The manual resource setting was recently removed from the ALSA drivers and I'd expect this can now go as a package-deal. Unfortunately, suspend / resume complicates things a bit, but PnP core can handle DO_NOT_CHANGE flag. But it will just mean - _preserve_ resource allocation from last suspend state for this device and enable hw physically before calling resume() callback. When resuming, wouldn't we *always* want to preserve the resource allocation from the last suspend, regardless of whether PNP_DRIVER_RES_DO_NOT_CHANGE is specified? Yes. Linux PNP definitely has issues with suspend/resume, and I suspect this is one of them. Rene. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/2] 8250_pnp: register x86 COM ports at the conventional ttyS names
On 16-01-08 21:42, H. Peter Anvin wrote: Bodo Eggert wrote: BTW1: These addresses may be used to detect ports on non-standard addresses, but unfortunately they don't tell the IRQ. BTW2: When I submitted a patch using the BIOS data area, I was told that it might not exist on systems booting from non-PC firmware. This claim was not yet backed with any knowledge, nor did anybody suggest a way to detect this situation. This is, of course, true. It doesn't exactly help that some (most?) non-PC firmware at least mimic the BIOS data area. In this particular case, there is some minor sanity-checking that can be done: the values should be nonzero and aligned 8. The number of places expected to contain something sensible should I believe first be verified at 0x410 -- the equipment word. Bits 11-9 (0x0e00) should be the number of serial ports, 0 to 4 (so 5-7 is also a sanity check) and if BIOSes can be expected to zero out the non-used base-addresses (at 0x400, 0x402, 0x404, 0x406) that's another sanity check. Don't know if they can though... Rene. -- 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: -mm: pnp-do-not-stop-start-devices-in-suspend-resume-path.patch breaks resuming isapnp cards
On 14-01-08 23:26, Bjorn Helgaas wrote: On Saturday 12 January 2008 11:13:35 pm Rene Herman wrote: I find DISABLE including DO_NOT_CHANGE rather unexpected... I don't know the history of those flags, but I wish they didn't exist. They really look like warts in the PNP core code. They're used so infrequently and without obvious rationale, that it seems like it'd be better if there were a way to deal with them inside the driver. I see, thanks for the comment. PNP_DRIVER_RES_DISABLE is used by ALSA only and used by _all_ ALSA ISA-PnP drivers (snd-sscape uses RES_DO_NOT_CHANGE instead but we should consider that one a consistency bug). RES_DO_NOT_CHANGE is used by drivers/pnp/system.c and rtc-cmos.c as well. I'll look at this. Getting rid of DISABLE as a first step should not be overly problematic. This might again be a left-over from days where no easy to use interface to PnP existed which it now does in echoing things into sysfs. Takashi: which reminds me -- crap, I promised to document more of that for ALSA use following up the recent pnp driver-side resource setting removal. Sorry, forgot, will do. This had to do with the excessive warnings about exceeding the maximum number of resources for a PNP device. This should be resolved by Len's patch here: http://bugzilla.kernel.org/show_bug.cgi?id=9535#c10 We all agree this is a stop-gap, and for 2.6.25, we need the real solution of making PNP resources fully dynamic. Thank you. Just pulled and see that's now indeed in. Wasn't in -rc7 yet... Rene. -- 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: -mm: pnp-do-not-stop-start-devices-in-suspend-resume-path.patch breaks resuming isapnp cards
On 14-01-08 23:26, Bjorn Helgaas wrote: On Saturday 12 January 2008 11:13:35 pm Rene Herman wrote: I find DISABLE including DO_NOT_CHANGE rather unexpected... I don't know the history of those flags, but I wish they didn't exist. They really look like warts in the PNP core code. They're used so infrequently and without obvious rationale, that it seems like it'd be better if there were a way to deal with them inside the driver. I see, thanks for the comment. PNP_DRIVER_RES_DISABLE is used by ALSA only and used by _all_ ALSA ISA-PnP drivers (snd-sscape uses RES_DO_NOT_CHANGE instead but we should consider that one a consistency bug). RES_DO_NOT_CHANGE is used by drivers/pnp/system.c and rtc-cmos.c as well. I'll look at this. Getting rid of DISABLE as a first step should not be overly problematic. This might again be a left-over from days where no easy to use interface to PnP existed which it now does in echoing things into sysfs. Takashi: which reminds me -- crap, I promised to document more of that for ALSA use following up the recent pnp driver-side resource setting removal. Sorry, forgot, will do. This had to do with the excessive warnings about exceeding the maximum number of resources for a PNP device. This should be resolved by Len's patch here: http://bugzilla.kernel.org/show_bug.cgi?id=9535#c10 We all agree this is a stop-gap, and for 2.6.25, we need the real solution of making PNP resources fully dynamic. Thank you. Just pulled and see that's now indeed in. Wasn't in -rc7 yet... Rene. -- 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: -mm: pnp-do-not-stop-start-devices-in-suspend-resume-path.patch breaks resuming isapnp cards
On 13-01-08 06:50, Bjorn Helgaas wrote: On Saturday 12 January 2008 1:08:01 pm Rene Herman wrote: pnp-do-not-stop-start-devices-in-suspend-resume-path.patch in current -mm breaks resuming isapnp cards from hibernation. They need the pnp_start_dev to enable the device again after hibernation. They don't really need the pnp_stop_dev() which the above mentioned patch also removes but with the pnp_start_dev() restored it seems pnp_stop_dev() should also stay. Bjorn Helgaas should decide -- currently the patch as you have it breaks drivers though. Could you drop it? Yes, please drop pnp-do-not-stop-start-devices-in-suspend-resume-path.patch for now. Okay, thanks for the reply. And, now that I have your attention, while it's not important to the issue anymore with the tests removed as the submitted patch did, do you have an opinion on (include/linux/pnp.h): /* pnp driver flags */ #define PNP_DRIVER_RES_DO_NOT_CHANGE0x0001 /* do not change the state of the device */ #define PNP_DRIVER_RES_DISABLE 0x0003 /* ensure the device is disabled */ I find DISABLE including DO_NOT_CHANGE rather unexpected... By the way, I also still have this next one outstanding for you... :-/ http://lkml.org/lkml/2008/1/9/168 Rene. -- 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/
-mm: pnp-do-not-stop-start-devices-in-suspend-resume-path.patch breaks resuming isapnp cards
Hi Andrew.
pnp-do-not-stop-start-devices-in-suspend-resume-path.patch in current -mm
breaks resuming isapnp cards from hibernation. They need the pnp_start_dev
to enable the device again after hibernation.
They don't really need the pnp_stop_dev() which the above mentioned patch
also removes but with the pnp_start_dev() restored it seems pnp_stop_dev()
should also stay. Bjorn Helgaas should decide -- currently the patch as you
have it breaks drivers though. Could you drop it?
Then, if so and after you do that, could you apply the attached? That's also
needed to resume (ALSA) ISA-PnP cards from hibernation due to the
RES_DO_NOT_CHANGE test triggering for ALSA drivers and the pnp_start_dev()
still not happening. More in the changelog...
On 12-01-08 20:08, Rafael J. Wysocki wrote:
On Saturday, 12 of January 2008, Rene Herman wrote:
It seems all PnP drivers would need to stick a pnp_start_dev in their resume
method
Yes.
then which means it really belongs in core.
Yes, if practical.
One important point where PnP and PCI differ is that PnP allows to change the
resources on a protocol level and I don't see how it could ever not be
necessary to restore the state a user may have set if power has been
removed. Hibernate is just that, isn't it?
Basically, yes, it is.
Rene.
commit 7d16e8b3e7739599d32c8006f9e84fadb86b8296
Author: Rene Herman <[EMAIL PROTECTED]>
Date: Sat Jan 12 00:00:35 2008 +0100
PNP: do not test PNP_DRIVER_RES_DO_NOT_CHANGE on suspend/resume
The PNP_DRIVER_RES_DO_NOT_CHANGE flag is meant to signify that
the PNP core should not change resources for the device -- not
that it shouldn't disable/enable the device on suspend/resume.
ALSA ISAPnP drivers set PNP_DRIVER_RES_DO_NOT_CHANAGE (0x0001)
through setting PNP_DRIVER_RES_DISABLE (0x0003). The latter
including the former may in itself be considered rather
unexpected but doesn't change that suspend/resume wouldn't seem
to have any business testing the flag.
As reported by Ondrej Zary for snd-cs4236, ALSA driven ISAPnP
cards don't survive swsusp hibernation with the resume skipping
setting the resources due to testing the flag -- the same test
in the suspend path isn't enough to keep hibernation from
disabling the card it seems.
These tests were added (in 2005) by Piere Ossman in commit
68094e3251a664ee1389fcf179497237cbf78331, "alsa: Improved PnP
suspend support" who doesn't remember why. This deletes them.
Signed-off-by: Rene Herman <[EMAIL PROTECTED]>
Tested-by: Ondrej Zary <[EMAIL PROTECTED]>
diff --git a/drivers/pnp/driver.c b/drivers/pnp/driver.c
index a262762..12a1645 100644
--- a/drivers/pnp/driver.c
+++ b/drivers/pnp/driver.c
@@ -161,8 +161,7 @@ static int pnp_bus_suspend(struct device *dev, pm_message_t
state)
return error;
}
- if (!(pnp_drv->flags & PNP_DRIVER_RES_DO_NOT_CHANGE) &&
- pnp_can_disable(pnp_dev)) {
+ if (pnp_can_disable(pnp_dev)) {
error = pnp_stop_dev(pnp_dev);
if (error)
return error;
@@ -185,14 +184,17 @@ static int pnp_bus_resume(struct device *dev)
if (pnp_dev->protocol && pnp_dev->protocol->resume)
pnp_dev->protocol->resume(pnp_dev);
- if (!(pnp_drv->flags & PNP_DRIVER_RES_DO_NOT_CHANGE)) {
+ if (pnp_can_write(pnp_dev)) {
error = pnp_start_dev(pnp_dev);
if (error)
return error;
}
- if (pnp_drv->resume)
- return pnp_drv->resume(pnp_dev);
+ if (pnp_drv->resume) {
+ error = pnp_drv->resume(pnp_dev);
+ if (error)
+ return error;
+ }
return 0;
}
Re: [alsa-devel] PNP_DRIVER_RES_DISABLE breaks swsusp at least with snd_cs4236
On 12-01-08 16:21, Pierre Ossman wrote: Ah, sorry. It was a different thread. Look for a mail with the subject "PNP: do not stop/start devices in suspend/resume path" in the LKML och linux-pm archives. Right, and I see that the removal of start/stop is already in -mm. That's not going to work. Something (such as removing power) disabled Ondrej's CS4236 and the pnp_start_dev() is needed to re-enable it upon resume. But we certainly need the pnp_start_dev() in the current flow of things. It not being called is the problem this fixes... I think the previous suggestion was that the drivers should call this, not the core, so that it behaved more like other parts of the kernel (e.g. PCI). It seems all PnP drivers would need to stick a pnp_start_dev in their resume method then which means it really belongs in core. One important point where PnP and PCI differ is that PnP allows to change the resources on a protocol level and I don't see how it could ever not be necessary to restore the state a user may have set if power has been removed. Hibernate is just that, isn't it? Rene. -- 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: [alsa-devel] PNP_DRIVER_RES_DISABLE breaks swsusp at least with snd_cs4236
On 12-01-08 12:12, Pierre Ossman wrote: On Sat, 12 Jan 2008 02:23:27 +0100 Rene Herman <[EMAIL PROTECTED]> wrote: Pavel, Rafael -- the attached fixes snd-cs4236 not coming back to life for Ondrej after hibernation due to the PNP_DRIVER_RES_DO_NOT_CHANGE test triggering in pnp_bus_resume() and keeping the card in a suspended state. I'm a bit confused here. Bjorn Helgaas wanted to remove the pnp_start/stop_dev() calls completely, and you want them called all the time. :) Wanted where? Haven't seen a coment from Bjorn? But -- while removing them both looks (as) sensible from a mirror-image viewpoint, this wouldn't fix the problem. As fas as I understand things, "hibernation" is basically "save state, shut down machine" where the latter step is going to disable the card inevitably. On resume, you're going to need to restore the resources (that were saved in pnp_dev->res) that it was using to the card, which is what pnp_start_dev() does -- it not being called is the current problem of the card not coming back to life. pnp_stop_dev() could go in this specific situation. Not much point in first disabling the thing it seems if a subsequent shutdown is going to take care of that anyway. However, suspend/resume isn't just called in the case of complete hibernation I guess and I know nothing about it all -- hence my request to the hiberhation people for how this is designed to be. But we certainly need the pnp_start_dev() in the current flow of things. It not being called is the problem this fixes... Rene. -- 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: [alsa-devel] PNP_DRIVER_RES_DISABLE breaks swsusp at least with snd_cs4236
On 12-01-08 12:12, Pierre Ossman wrote: On Sat, 12 Jan 2008 02:23:27 +0100 Rene Herman [EMAIL PROTECTED] wrote: Pavel, Rafael -- the attached fixes snd-cs4236 not coming back to life for Ondrej after hibernation due to the PNP_DRIVER_RES_DO_NOT_CHANGE test triggering in pnp_bus_resume() and keeping the card in a suspended state. I'm a bit confused here. Bjorn Helgaas wanted to remove the pnp_start/stop_dev() calls completely, and you want them called all the time. :) Wanted where? Haven't seen a coment from Bjorn? But -- while removing them both looks (as) sensible from a mirror-image viewpoint, this wouldn't fix the problem. As fas as I understand things, hibernation is basically save state, shut down machine where the latter step is going to disable the card inevitably. On resume, you're going to need to restore the resources (that were saved in pnp_dev-res) that it was using to the card, which is what pnp_start_dev() does -- it not being called is the current problem of the card not coming back to life. pnp_stop_dev() could go in this specific situation. Not much point in first disabling the thing it seems if a subsequent shutdown is going to take care of that anyway. However, suspend/resume isn't just called in the case of complete hibernation I guess and I know nothing about it all -- hence my request to the hiberhation people for how this is designed to be. But we certainly need the pnp_start_dev() in the current flow of things. It not being called is the problem this fixes... Rene. -- 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: [alsa-devel] PNP_DRIVER_RES_DISABLE breaks swsusp at least with snd_cs4236
On 12-01-08 16:21, Pierre Ossman wrote: Ah, sorry. It was a different thread. Look for a mail with the subject PNP: do not stop/start devices in suspend/resume path in the LKML och linux-pm archives. Right, and I see that the removal of start/stop is already in -mm. That's not going to work. Something (such as removing power) disabled Ondrej's CS4236 and the pnp_start_dev() is needed to re-enable it upon resume. But we certainly need the pnp_start_dev() in the current flow of things. It not being called is the problem this fixes... I think the previous suggestion was that the drivers should call this, not the core, so that it behaved more like other parts of the kernel (e.g. PCI). It seems all PnP drivers would need to stick a pnp_start_dev in their resume method then which means it really belongs in core. One important point where PnP and PCI differ is that PnP allows to change the resources on a protocol level and I don't see how it could ever not be necessary to restore the state a user may have set if power has been removed. Hibernate is just that, isn't it? Rene. -- 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/
-mm: pnp-do-not-stop-start-devices-in-suspend-resume-path.patch breaks resuming isapnp cards
Hi Andrew.
pnp-do-not-stop-start-devices-in-suspend-resume-path.patch in current -mm
breaks resuming isapnp cards from hibernation. They need the pnp_start_dev
to enable the device again after hibernation.
They don't really need the pnp_stop_dev() which the above mentioned patch
also removes but with the pnp_start_dev() restored it seems pnp_stop_dev()
should also stay. Bjorn Helgaas should decide -- currently the patch as you
have it breaks drivers though. Could you drop it?
Then, if so and after you do that, could you apply the attached? That's also
needed to resume (ALSA) ISA-PnP cards from hibernation due to the
RES_DO_NOT_CHANGE test triggering for ALSA drivers and the pnp_start_dev()
still not happening. More in the changelog...
On 12-01-08 20:08, Rafael J. Wysocki wrote:
On Saturday, 12 of January 2008, Rene Herman wrote:
It seems all PnP drivers would need to stick a pnp_start_dev in their resume
method
Yes.
then which means it really belongs in core.
Yes, if practical.
One important point where PnP and PCI differ is that PnP allows to change the
resources on a protocol level and I don't see how it could ever not be
necessary to restore the state a user may have set if power has been
removed. Hibernate is just that, isn't it?
Basically, yes, it is.
Rene.
commit 7d16e8b3e7739599d32c8006f9e84fadb86b8296
Author: Rene Herman [EMAIL PROTECTED]
Date: Sat Jan 12 00:00:35 2008 +0100
PNP: do not test PNP_DRIVER_RES_DO_NOT_CHANGE on suspend/resume
The PNP_DRIVER_RES_DO_NOT_CHANGE flag is meant to signify that
the PNP core should not change resources for the device -- not
that it shouldn't disable/enable the device on suspend/resume.
ALSA ISAPnP drivers set PNP_DRIVER_RES_DO_NOT_CHANAGE (0x0001)
through setting PNP_DRIVER_RES_DISABLE (0x0003). The latter
including the former may in itself be considered rather
unexpected but doesn't change that suspend/resume wouldn't seem
to have any business testing the flag.
As reported by Ondrej Zary for snd-cs4236, ALSA driven ISAPnP
cards don't survive swsusp hibernation with the resume skipping
setting the resources due to testing the flag -- the same test
in the suspend path isn't enough to keep hibernation from
disabling the card it seems.
These tests were added (in 2005) by Piere Ossman in commit
68094e3251a664ee1389fcf179497237cbf78331, alsa: Improved PnP
suspend support who doesn't remember why. This deletes them.
Signed-off-by: Rene Herman [EMAIL PROTECTED]
Tested-by: Ondrej Zary [EMAIL PROTECTED]
diff --git a/drivers/pnp/driver.c b/drivers/pnp/driver.c
index a262762..12a1645 100644
--- a/drivers/pnp/driver.c
+++ b/drivers/pnp/driver.c
@@ -161,8 +161,7 @@ static int pnp_bus_suspend(struct device *dev, pm_message_t
state)
return error;
}
- if (!(pnp_drv-flags PNP_DRIVER_RES_DO_NOT_CHANGE)
- pnp_can_disable(pnp_dev)) {
+ if (pnp_can_disable(pnp_dev)) {
error = pnp_stop_dev(pnp_dev);
if (error)
return error;
@@ -185,14 +184,17 @@ static int pnp_bus_resume(struct device *dev)
if (pnp_dev-protocol pnp_dev-protocol-resume)
pnp_dev-protocol-resume(pnp_dev);
- if (!(pnp_drv-flags PNP_DRIVER_RES_DO_NOT_CHANGE)) {
+ if (pnp_can_write(pnp_dev)) {
error = pnp_start_dev(pnp_dev);
if (error)
return error;
}
- if (pnp_drv-resume)
- return pnp_drv-resume(pnp_dev);
+ if (pnp_drv-resume) {
+ error = pnp_drv-resume(pnp_dev);
+ if (error)
+ return error;
+ }
return 0;
}
Re: -mm: pnp-do-not-stop-start-devices-in-suspend-resume-path.patch breaks resuming isapnp cards
On 13-01-08 06:50, Bjorn Helgaas wrote: On Saturday 12 January 2008 1:08:01 pm Rene Herman wrote: pnp-do-not-stop-start-devices-in-suspend-resume-path.patch in current -mm breaks resuming isapnp cards from hibernation. They need the pnp_start_dev to enable the device again after hibernation. They don't really need the pnp_stop_dev() which the above mentioned patch also removes but with the pnp_start_dev() restored it seems pnp_stop_dev() should also stay. Bjorn Helgaas should decide -- currently the patch as you have it breaks drivers though. Could you drop it? Yes, please drop pnp-do-not-stop-start-devices-in-suspend-resume-path.patch for now. Okay, thanks for the reply. And, now that I have your attention, while it's not important to the issue anymore with the tests removed as the submitted patch did, do you have an opinion on (include/linux/pnp.h): /* pnp driver flags */ #define PNP_DRIVER_RES_DO_NOT_CHANGE0x0001 /* do not change the state of the device */ #define PNP_DRIVER_RES_DISABLE 0x0003 /* ensure the device is disabled */ I find DISABLE including DO_NOT_CHANGE rather unexpected... By the way, I also still have this next one outstanding for you... :-/ http://lkml.org/lkml/2008/1/9/168 Rene. -- 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: [alsa-devel] PNP_DRIVER_RES_DISABLE breaks swsusp at least with snd_cs4236
On 11-01-08 19:40, Ondrej Zary wrote:
On Friday 11 January 2008 15:21:55 Rene Herman wrote:
Hrmpf. Well, okay. Ondrej -- I assume this patch fixes things?
Yes, it works fine. 3c509 card still does not work after resume, but that
looks like another problem.
Okay. Would now only still like to know why the test in resume() means
trouble for you while it seems the same test in suspend() should've
triggered as well and not have stopped the device in the first place.
Know absolutely nothing about hibernation so added the listed maintainers to
the CC.
Pavel, Rafael -- the attached fixes snd-cs4236 not coming back to life for
Ondrej after hibernation due to the PNP_DRIVER_RES_DO_NOT_CHANGE test
triggering in pnp_bus_resume() and keeping the card in a suspended state.
There's issues on wether or not the flag _should_ be set (that is, be part
of PNP_DRIVER_RES_DISABLE) and that it shouldn't be tested by these code
patchs in the first place, but is it in fact expected that this would be
neccessary?
That is, is it expected/designed that the same test in pnp_bus_suspend()
didn't cause the device to not be disabled in the first place?
Rene.
commit 7d16e8b3e7739599d32c8006f9e84fadb86b8296
Author: Rene Herman <[EMAIL PROTECTED]>
Date: Sat Jan 12 00:00:35 2008 +0100
PNP: do not test PNP_DRIVER_RES_DO_NOT_CHANGE on suspend/resume
The PNP_DRIVER_RES_DO_NOT_CHANGE flag is meant to signify that
the PNP core should not change resources for the device -- not
that it shouldn't disable/enable the device on suspend/resume.
ALSA ISAPnP drivers set PNP_DRIVER_RES_DO_NOT_CHANAGE (0x0001)
through setting PNP_DRIVER_RES_DISABLE (0x0003). The latter
including the former may in itself be considered rather
unexpected but doesn't change that suspend/resume wouldn't seem
to have any business testing the flag.
As reported by Ondrej Zary for snd-cs4236, ALSA driven ISAPnP
cards don't survive swsusp hibernation with the resume skipping
setting the resources due to testing the flag -- the same test
in the suspend path isn't enough to keep hibernation from
disabling the card it seems.
These tests were added (in 2005) by Piere Ossman in commit
68094e3251a664ee1389fcf179497237cbf78331, "alsa: Improved PnP
suspend support" who doesn't remember why. This deletes them.
Signed-off-by: Rene Herman <[EMAIL PROTECTED]>
Tested-by: Ondrej Zary <[EMAIL PROTECTED]>
diff --git a/drivers/pnp/driver.c b/drivers/pnp/driver.c
index a262762..12a1645 100644
--- a/drivers/pnp/driver.c
+++ b/drivers/pnp/driver.c
@@ -161,8 +161,7 @@ static int pnp_bus_suspend(struct device *dev, pm_message_t
state)
return error;
}
- if (!(pnp_drv->flags & PNP_DRIVER_RES_DO_NOT_CHANGE) &&
- pnp_can_disable(pnp_dev)) {
+ if (pnp_can_disable(pnp_dev)) {
error = pnp_stop_dev(pnp_dev);
if (error)
return error;
@@ -185,14 +184,17 @@ static int pnp_bus_resume(struct device *dev)
if (pnp_dev->protocol && pnp_dev->protocol->resume)
pnp_dev->protocol->resume(pnp_dev);
- if (!(pnp_drv->flags & PNP_DRIVER_RES_DO_NOT_CHANGE)) {
+ if (pnp_can_write(pnp_dev)) {
error = pnp_start_dev(pnp_dev);
if (error)
return error;
}
- if (pnp_drv->resume)
- return pnp_drv->resume(pnp_dev);
+ if (pnp_drv->resume) {
+ error = pnp_drv->resume(pnp_dev);
+ if (error)
+ return error;
+ }
return 0;
}
Re: [linux-kernel] Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On 11-01-08 15:35, David P. Reed wrote: Rene Herman wrote: On 11-01-08 02:36, Zachary Amsden wrote: FWIW, I fixed the problem locally by recompiling, changing port 80 to port 84 in io.h; works great, and doesn't conflict with any occupied ports. Might not give you a "proper" delay though. 0xed should be a better choice... I don't think there is any magic here. Golly, you don't think so? Just commenting on his local hack. Port 0x84 is inside the (reserved) DMA page register range and stands a better chance of not being echoed onto ISA by various chipsets than 0xed does due to that. Yes -- on a sane machine it's all useless anyway and with all sane machines this discussion would've ended quite some time ago already. It's the insane, obsolete legacy junk that's the problem. Rene. -- 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: [alsa-devel] PNP_DRIVER_RES_DISABLE breaks swsusp at least with snd_cs4236
On 11-01-08 08:01, Pierre Ossman wrote: On Fri, 11 Jan 2008 02:19:07 +0100 Rene Herman <[EMAIL PROTECTED]> wrote: I see a PnP resume _consists_ of setting the resources so I can see the test implementation wise, but yes, conceptually it seems this test shouldn't be present. So just like the attached then? Pierre, what was the idea here? Added the other SOBs to the CC as well... You assume there was an idea? ;) I don't remember why things were done the way they were. And I can't find any clues in the correspondence around the issue. So your guess is as good as mine. Hrmpf. Well, okay. Ondrej -- I assume this patch fixes things? Rene. -- 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: [linux-kernel] Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On 11-01-08 15:35, David P. Reed wrote: Rene Herman wrote: On 11-01-08 02:36, Zachary Amsden wrote: FWIW, I fixed the problem locally by recompiling, changing port 80 to port 84 in io.h; works great, and doesn't conflict with any occupied ports. Might not give you a proper delay though. 0xed should be a better choice... I don't think there is any magic here. Golly, you don't think so? Just commenting on his local hack. Port 0x84 is inside the (reserved) DMA page register range and stands a better chance of not being echoed onto ISA by various chipsets than 0xed does due to that. Yes -- on a sane machine it's all useless anyway and with all sane machines this discussion would've ended quite some time ago already. It's the insane, obsolete legacy junk that's the problem. Rene. -- 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: [alsa-devel] PNP_DRIVER_RES_DISABLE breaks swsusp at least with snd_cs4236
On 11-01-08 08:01, Pierre Ossman wrote: On Fri, 11 Jan 2008 02:19:07 +0100 Rene Herman [EMAIL PROTECTED] wrote: I see a PnP resume _consists_ of setting the resources so I can see the test implementation wise, but yes, conceptually it seems this test shouldn't be present. So just like the attached then? Pierre, what was the idea here? Added the other SOBs to the CC as well... You assume there was an idea? ;) I don't remember why things were done the way they were. And I can't find any clues in the correspondence around the issue. So your guess is as good as mine. Hrmpf. Well, okay. Ondrej -- I assume this patch fixes things? Rene. -- 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: [alsa-devel] PNP_DRIVER_RES_DISABLE breaks swsusp at least with snd_cs4236
On 11-01-08 19:40, Ondrej Zary wrote:
On Friday 11 January 2008 15:21:55 Rene Herman wrote:
Hrmpf. Well, okay. Ondrej -- I assume this patch fixes things?
Yes, it works fine. 3c509 card still does not work after resume, but that
looks like another problem.
Okay. Would now only still like to know why the test in resume() means
trouble for you while it seems the same test in suspend() should've
triggered as well and not have stopped the device in the first place.
Know absolutely nothing about hibernation so added the listed maintainers to
the CC.
Pavel, Rafael -- the attached fixes snd-cs4236 not coming back to life for
Ondrej after hibernation due to the PNP_DRIVER_RES_DO_NOT_CHANGE test
triggering in pnp_bus_resume() and keeping the card in a suspended state.
There's issues on wether or not the flag _should_ be set (that is, be part
of PNP_DRIVER_RES_DISABLE) and that it shouldn't be tested by these code
patchs in the first place, but is it in fact expected that this would be
neccessary?
That is, is it expected/designed that the same test in pnp_bus_suspend()
didn't cause the device to not be disabled in the first place?
Rene.
commit 7d16e8b3e7739599d32c8006f9e84fadb86b8296
Author: Rene Herman [EMAIL PROTECTED]
Date: Sat Jan 12 00:00:35 2008 +0100
PNP: do not test PNP_DRIVER_RES_DO_NOT_CHANGE on suspend/resume
The PNP_DRIVER_RES_DO_NOT_CHANGE flag is meant to signify that
the PNP core should not change resources for the device -- not
that it shouldn't disable/enable the device on suspend/resume.
ALSA ISAPnP drivers set PNP_DRIVER_RES_DO_NOT_CHANAGE (0x0001)
through setting PNP_DRIVER_RES_DISABLE (0x0003). The latter
including the former may in itself be considered rather
unexpected but doesn't change that suspend/resume wouldn't seem
to have any business testing the flag.
As reported by Ondrej Zary for snd-cs4236, ALSA driven ISAPnP
cards don't survive swsusp hibernation with the resume skipping
setting the resources due to testing the flag -- the same test
in the suspend path isn't enough to keep hibernation from
disabling the card it seems.
These tests were added (in 2005) by Piere Ossman in commit
68094e3251a664ee1389fcf179497237cbf78331, alsa: Improved PnP
suspend support who doesn't remember why. This deletes them.
Signed-off-by: Rene Herman [EMAIL PROTECTED]
Tested-by: Ondrej Zary [EMAIL PROTECTED]
diff --git a/drivers/pnp/driver.c b/drivers/pnp/driver.c
index a262762..12a1645 100644
--- a/drivers/pnp/driver.c
+++ b/drivers/pnp/driver.c
@@ -161,8 +161,7 @@ static int pnp_bus_suspend(struct device *dev, pm_message_t
state)
return error;
}
- if (!(pnp_drv-flags PNP_DRIVER_RES_DO_NOT_CHANGE)
- pnp_can_disable(pnp_dev)) {
+ if (pnp_can_disable(pnp_dev)) {
error = pnp_stop_dev(pnp_dev);
if (error)
return error;
@@ -185,14 +184,17 @@ static int pnp_bus_resume(struct device *dev)
if (pnp_dev-protocol pnp_dev-protocol-resume)
pnp_dev-protocol-resume(pnp_dev);
- if (!(pnp_drv-flags PNP_DRIVER_RES_DO_NOT_CHANGE)) {
+ if (pnp_can_write(pnp_dev)) {
error = pnp_start_dev(pnp_dev);
if (error)
return error;
}
- if (pnp_drv-resume)
- return pnp_drv-resume(pnp_dev);
+ if (pnp_drv-resume) {
+ error = pnp_drv-resume(pnp_dev);
+ if (error)
+ return error;
+ }
return 0;
}
Re: [linux-kernel] Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On 11-01-08 02:36, Zachary Amsden wrote: FWIW, I fixed the problem locally by recompiling, changing port 80 to port 84 in io.h; works great, and doesn't conflict with any occupied ports. Might not give you a "proper" delay though. 0xed should be a better choice... Rene. -- 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: [alsa-devel] PNP_DRIVER_RES_DISABLE breaks swsusp at least with snd_cs4236
On 10-01-08 08:58, Jaroslav Kysela wrote:
On Thu, 10 Jan 2008, Rene Herman wrote:
On 09-01-08 23:43, Ondrej Zary wrote:
Jaroslav -- in your role as ISA-PnP maintainer and Bjorn, in yours as
having been foollish enough to touch PnP recently:
as hibernation (swsusp) started to work with my CPU, I found that my Turtle
Beach Malibu stops working after resume from hibernation. It's caused by fact
that the card is not enabled on the pnp layer during resume - and thus card
registers are inaccessible (reads return FFs, writes go nowhere).
During resume, pnp_bus_resume() in drivers/pnp/driver.c is called for each pnp
device. This function calls pnp_start_dev() only when the
PNP_DRIVER_RES_DO_NOT_CHANGE bit is NOT seting pnp_drv->flags. But the cs4236
driver in sound/isa/cs423x/cs4236.c explicitly sets the .flags to
PNP_DRIVER_RES_DISABLE - it's value is 3 and that includes
PNP_DRIVER_RES_DO_NOT_CHANGE bit.
Ehm. Isn't that a bit unexpected:
#define PNP_DRIVER_RES_DO_NOT_CHANGE0x0001 /* do not change the state
of the device */
#define PNP_DRIVER_RES_DISABLE 0x0003 /* ensure the device is
disabled */
I'd say that disabling is changing, so isn't this just a braino where
someone meant to write 2 instead of 3?
It's irrelevant. I think that condition in driver.c in suspend and resume
callbacks is invalid, because PNP_DRIVER_RES_DO_NOT_CHANGE means that
resources should not be changed in the pnp core but only in the driver,
but in suspend/resume process are resources preserved, so the condition
should be removed.
I see a PnP resume _consists_ of setting the resources so I can see the test
implementation wise, but yes, conceptually it seems this test shouldn't be
present. So just like the attached then?
Pierre, what was the idea here? Added the other SOBs to the CC as well...
Author of this code is:
author Pierre Ossman <[EMAIL PROTECTED]> Tue, 29 Nov 2005 09:09:32 +0100
committer Jaroslav Kysela <[EMAIL PROTECTED]> Tue, 03 Jan 2006 12:31:30 +0100
[ALSA] [PATCH] alsa: Improved PnP suspend support
Also use the PnP functions to start/stop the devices during the suspend so
that drivers will not have to duplicate this code.
Cc: Adam Belay <[EMAIL PROTECTED]>
Cc: Jaroslav Kysela <[EMAIL PROTECTED]>
Cc: Takashi Iwai <[EMAIL PROTECTED]>
Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Takashi Iwai <[EMAIL PROTECTED]>
Rene.
diff --git a/drivers/pnp/driver.c b/drivers/pnp/driver.c
index a262762..12a1645 100644
--- a/drivers/pnp/driver.c
+++ b/drivers/pnp/driver.c
@@ -161,8 +161,7 @@ static int pnp_bus_suspend(struct device *dev, pm_message_t
state)
return error;
}
- if (!(pnp_drv->flags & PNP_DRIVER_RES_DO_NOT_CHANGE) &&
- pnp_can_disable(pnp_dev)) {
+ if (pnp_can_disable(pnp_dev)) {
error = pnp_stop_dev(pnp_dev);
if (error)
return error;
@@ -185,14 +184,17 @@ static int pnp_bus_resume(struct device *dev)
if (pnp_dev->protocol && pnp_dev->protocol->resume)
pnp_dev->protocol->resume(pnp_dev);
- if (!(pnp_drv->flags & PNP_DRIVER_RES_DO_NOT_CHANGE)) {
+ if (pnp_can_write(pnp_dev)) {
error = pnp_start_dev(pnp_dev);
if (error)
return error;
}
- if (pnp_drv->resume)
- return pnp_drv->resume(pnp_dev);
+ if (pnp_drv->resume) {
+ error = pnp_drv->resume(pnp_dev);
+ if (error)
+ return error;
+ }
return 0;
}
Re: [alsa-devel] PNP_DRIVER_RES_DISABLE breaks swsusp at least with snd_cs4236
On 10-01-08 08:58, Jaroslav Kysela wrote:
On Thu, 10 Jan 2008, Rene Herman wrote:
On 09-01-08 23:43, Ondrej Zary wrote:
Jaroslav -- in your role as ISA-PnP maintainer and Bjorn, in yours as
having been foollish enough to touch PnP recently:
as hibernation (swsusp) started to work with my CPU, I found that my Turtle
Beach Malibu stops working after resume from hibernation. It's caused by fact
that the card is not enabled on the pnp layer during resume - and thus card
registers are inaccessible (reads return FFs, writes go nowhere).
During resume, pnp_bus_resume() in drivers/pnp/driver.c is called for each pnp
device. This function calls pnp_start_dev() only when the
PNP_DRIVER_RES_DO_NOT_CHANGE bit is NOT seting pnp_drv-flags. But the cs4236
driver in sound/isa/cs423x/cs4236.c explicitly sets the .flags to
PNP_DRIVER_RES_DISABLE - it's value is 3 and that includes
PNP_DRIVER_RES_DO_NOT_CHANGE bit.
Ehm. Isn't that a bit unexpected:
#define PNP_DRIVER_RES_DO_NOT_CHANGE0x0001 /* do not change the state
of the device */
#define PNP_DRIVER_RES_DISABLE 0x0003 /* ensure the device is
disabled */
I'd say that disabling is changing, so isn't this just a braino where
someone meant to write 2 instead of 3?
It's irrelevant. I think that condition in driver.c in suspend and resume
callbacks is invalid, because PNP_DRIVER_RES_DO_NOT_CHANGE means that
resources should not be changed in the pnp core but only in the driver,
but in suspend/resume process are resources preserved, so the condition
should be removed.
I see a PnP resume _consists_ of setting the resources so I can see the test
implementation wise, but yes, conceptually it seems this test shouldn't be
present. So just like the attached then?
Pierre, what was the idea here? Added the other SOBs to the CC as well...
Author of this code is:
author Pierre Ossman [EMAIL PROTECTED] Tue, 29 Nov 2005 09:09:32 +0100
committer Jaroslav Kysela [EMAIL PROTECTED] Tue, 03 Jan 2006 12:31:30 +0100
[ALSA] [PATCH] alsa: Improved PnP suspend support
Also use the PnP functions to start/stop the devices during the suspend so
that drivers will not have to duplicate this code.
Cc: Adam Belay [EMAIL PROTECTED]
Cc: Jaroslav Kysela [EMAIL PROTECTED]
Cc: Takashi Iwai [EMAIL PROTECTED]
Signed-off-by: Pierre Ossman [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Takashi Iwai [EMAIL PROTECTED]
Rene.
diff --git a/drivers/pnp/driver.c b/drivers/pnp/driver.c
index a262762..12a1645 100644
--- a/drivers/pnp/driver.c
+++ b/drivers/pnp/driver.c
@@ -161,8 +161,7 @@ static int pnp_bus_suspend(struct device *dev, pm_message_t
state)
return error;
}
- if (!(pnp_drv-flags PNP_DRIVER_RES_DO_NOT_CHANGE)
- pnp_can_disable(pnp_dev)) {
+ if (pnp_can_disable(pnp_dev)) {
error = pnp_stop_dev(pnp_dev);
if (error)
return error;
@@ -185,14 +184,17 @@ static int pnp_bus_resume(struct device *dev)
if (pnp_dev-protocol pnp_dev-protocol-resume)
pnp_dev-protocol-resume(pnp_dev);
- if (!(pnp_drv-flags PNP_DRIVER_RES_DO_NOT_CHANGE)) {
+ if (pnp_can_write(pnp_dev)) {
error = pnp_start_dev(pnp_dev);
if (error)
return error;
}
- if (pnp_drv-resume)
- return pnp_drv-resume(pnp_dev);
+ if (pnp_drv-resume) {
+ error = pnp_drv-resume(pnp_dev);
+ if (error)
+ return error;
+ }
return 0;
}
