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: 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: 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: 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 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: 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/
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: "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 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 - 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 pnp_check_po
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
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: 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 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: [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: -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 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 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 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? The same .flags value is present in many of the ALSA ISA sound drivers. Removing that .flags line caused this to appear inlog when loading snd_cs4236 module: CS4236+ WSS PnP manual resources are invalid, using auto config CS4236+ CTRL PnP manual resources are invalid, using auto config CS4236+ MPU401 PnP manual resources are invalid, using auto config and the sound now works after resume! So the question is: why is this line present? Is this a bug? What's the correct 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: [linux-kernel] Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On 10-01-08 01:37, Robert Hancock wrote: David P. Reed wrote: I have a small suggestion in mind that might be helpful in the future: the "motherboard resources" discovered as PNP0C02 devices in their _CRS settings in ACPI during ACPI PnP startup should be reserved (or checked), and any drivers that still use port 80 implicitly should reserve that port. I agree. In this case the BIOS on these laptops is trying to tell us "port 80 is used for our purposes, do not touch it". We should be listening. Listening is fine but what are you going to do after you have listened? Right, not use port 0x80 but since that's the current idea anyway outside of legacy drivers, you don't actually need to listen. If the quirk-to-0xed or similar was to stay, it's a much better switching point than DMI strings but if not, it's not actually important. 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 09-01-08 06:30, Christer Weinigel wrote: On Tue, 08 Jan 2008 18:52:42 -0800 Zachary Amsden <[EMAIL PROTECTED]> wrote: What is the outcome of this thread? Are we going to use timing based port delays, or can we finally drop these things entirely on 64-bit architectures? I a have a doubly vested interest in this, both as the owner of an affected HP dv9210us laptop and as a maintainer of paravirt code - and would like 64-bit Linux code to stop using I/O to port 0x80 in both cases (as I suspect would every other person involved with virtualization). I've tried to follow this thread, but with all the jabs, 1-ups, and obscure legacy hardware pageantry going on, it isn't clear what we're really doing. I belive Alan Cox is doing a review of some drivers, to see if they actually need the I/O port delay. A lot of drivers probably use outb_p just because it was copy-pasted from some other driver and it can be removed. Alan's review has also brought to light a lack of locking in some drivers, so I think Alan has been adding proper locking to some of the watchdog drivers. Yes, Alan should be considered to be in the driver seat here (and current x86.git changes should be tossed). Most old ISA only device drivers can keep using OUT 80h. They are not used on modern machines and it's better to keep them unchanged to avoid unneccesary incompatibilities. As far as I know, the 8253 PIT timer code needs outb_p on some older platform, and this is one of the most troublesome since the same PIT controller (or a register compatible one) has been used since the original IBM PC, and it is frequently executed code. Ingo Molnar has done an alternate implementation of the PIT clock source which uses udelay instead of OUT 80h to delay accesses to the ports. The kernel could make a choice of which variant to use based on the DMI year, if compiling for x86_64, or something similar. Maybe have a command line option too. Just udelay() should be fine after "fixing" udelay() to be somewhat usefully defined pre-calibration. The keyboard controller on some platform needs the delay, and the same driver is used on both ancient and modern systems, I think it can be changed to udelay since it's not so time critical code. The 8259 interrupt controller on some platform needs the delay, I think it can be changed to udelay since it's only some setup code that uses outb_p. I guess there are time critical accesses to the interrupt controller from assembly code somewhere to acknowledge interrupts, and that code needs a review. I'd not expect very time crtical. The current outb_p use gives a delay somewhere between .5 and 2 microseconds as per earlier survey meaning a udelay(1) or 2 would be enough -- again, at the point that udelay() is sensible. New machines don't use the legacy PIC anymore anyway. The floppy controller code uses outb_p. Even though there might be floppy controllers on modern systems, I'd rather leave the floppy code alone since it's supposed to be very fragile. If you still use floppies you deserve what you get. Floppies forever. In practice, leaving it alone isn't going to matter, but in that same practice changing it to udelay() probably doesn't either. The ones to leave alone are the ones that are clumsy/impossible to test and the ones such as in NIC drivers that were specifically tuned. Some specific drivers, such as drivers for 8390 or 8390 clone based network cards are also a bit troublesome, they do need outb_p (and the delay for the original 8390 chip is specified in bus cycles), and there can be a big performance loss if pessimistic udelays are used for the delay. There are still a bunch of PCMCIA cards based on that chip which means that those cards can be used with modern machines. There are also PCI and memory mapped variants of the 8390, some of them new designs which are only register compatible, some other designs are using a real 8390 with a FPGA used as glue logic. I think Alan suggested compiling two versions of that driver, one with OUT 80h, and one with udelay. Old machines can choose the old driver, and new machines can use the new one. Other drivers can probably do the same thing, or if not time critical, always use a pessimistic udelay. Not sure what the final suggestion for those was either As for the implementation, I like the suggestion to split outb_b into two calls, one to outb and one to isa_slow_down_io. It makes it very obvious that it is really two function calls, and that it needs locking. For those uses that are not ISA port accesses, isa_slow_down_io should be changed to an appropriate udelay instead. ... or simply deleted. The current outb_p is "outb; slow_down_io" as a macro so that with this you also get no binary changes, making it rather easy to prove that things do not change timing in cases where you keep the delay. (they're not so much function calls though -- they're inlined). The goal is anyway that a modern machine sho
Re: pnpacpi : exceeded the max number of IO resources
On 09-01-08 10:34, Frans Pop wrote:
Bjorn:
Len Brown wrote:
Well, yes, the warning is actually new as well. Previously your kernel
just silently ignored 8 more mem resources than it does now it seems.
Given that people are hitting these limits, it might make sense to just
do away with the warning for 2.6.24 again while waiting for the dynamic
code?
Ping. Should these warnings be reverted for 2.6.24?
No. I don't think hiding this issue again is a good idea.
I'd rather live with people complaining about an addition dmesg line.
We're not talking about "a" additional line. In my case [1] we're talking
about 22 (!) additional identical lines.
You lucky devil. Someone else reported 92 if I remember rightly. This really
needs to be called a 2.6.24 bug. Stick the word "regression" in the subject
line and someone will notice...
The warning might provide useful information to someone looking at a dmesg
but given that people are hitting them way too hard with the only difference
versus 2.6.23 being tke kernel now complaining about it, they're not useful
enough to be printed more than once, or at more then DEBUG level or even at
all in fact since we already know the static limit isn't enough for everyone
and needs be turned dynamic -- really, what else is someone going to debug
with it?
I'd consider Bjorn Helgaas the PnP maintainer and he earlier agreed that
this needed something:
http://lkml.org/lkml/2007/12/5/301
Printing the warning only once per type as per attached fixes the problenm
as well.
Bjorn, could you push your preference into 2.6.24?
Not fixing this before 2.6.24 seems completely inconsistent:
- either this is a real bug and the ERR level message is correct, in which
case the limits should be increased;
- or hitting the limits is harmless and the message should be changed to
DEBUG level.
It is great to hear that the memory allocation will become dynamic in the
future and maybe that could just justify your standpoint, but having the
messages is damn ugly and alarming from a user point of view.
Please keep in mind that depending on distro release schedules, 2.6.24 could
live for quite a bit longer than just the period needed to release 2.6.25
(if that is when the dynamic allocation will be implemented).
Cheers,
FJP
[1] http://lkml.org/lkml/2008/1/6/279
diff --git a/drivers/pnp/pnpacpi/rsparser.c b/drivers/pnp/pnpacpi/rsparser.c
index 3c5eb37..cd9d4a8 100644
--- a/drivers/pnp/pnpacpi/rsparser.c
+++ b/drivers/pnp/pnpacpi/rsparser.c
@@ -73,6 +73,7 @@ static void pnpacpi_parse_allocated_irqresource(struct
pnp_resource_table *res,
u32 gsi, int triggering,
int polarity, int shareable)
{
+ static int warned;
int i = 0;
int irq;
int p, t;
@@ -84,8 +85,9 @@ static void pnpacpi_parse_allocated_irqresource(struct
pnp_resource_table *res,
i < PNP_MAX_IRQ)
i++;
if (i >= PNP_MAX_IRQ) {
- printk(KERN_ERR "pnpacpi: exceeded the max number of IRQ "
- "resources: %d \n", PNP_MAX_IRQ);
+ if (!warned++)
+ printk(KERN_ERR "pnpacpi: exceeded the max number of
IRQ "
+ "resources: %d \n", PNP_MAX_IRQ);
return;
}
/*
@@ -168,6 +170,7 @@ static void pnpacpi_parse_allocated_dmaresource(struct
pnp_resource_table *res,
u32 dma, int type,
int bus_master, int transfer)
{
+ static int warned;
int i = 0;
while (i < PNP_MAX_DMA &&
@@ -183,7 +186,7 @@ static void pnpacpi_parse_allocated_dmaresource(struct
pnp_resource_table *res,
}
res->dma_resource[i].start = dma;
res->dma_resource[i].end = dma;
- } else {
+ } else if (!warned++) {
printk(KERN_ERR "pnpacpi: exceeded the max number of DMA "
"resources: %d \n", PNP_MAX_DMA);
}
@@ -192,6 +195,7 @@ static void pnpacpi_parse_allocated_dmaresource(struct
pnp_resource_table *res,
static void pnpacpi_parse_allocated_ioresource(struct pnp_resource_table *res,
u64 io, u64 len, int io_decode)
{
+ static int warned;
int i = 0;
while (!(res->port_resource[i].flags & IORESOURCE_UNSET) &&
@@ -207,7 +211,7 @@ static void pnpacpi_parse_allocated_ioresource(struct
pnp_resource_table *res,
}
res->port_resource[i].start = io;
res->port_resource[i].end = io + len - 1;
- } else {
+ } else if (!warned++) {
printk(KERN_ERR "pnpacpi: exceeded the max number of IO "
"resources: %d \n", PNP_MAX_PORT);
}
@@ -217,6 +221,7 @@ static void pn
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On 08-01-08 13:51, Bodo Eggert wrote: On Tue, 8 Jan 2008, Rene Herman wrote: Is this only about the ones then left for things like legacy PIC and PIT? Does anyone care about just sticking in a udelay(2) (or 1) there as a replacement and call it a day? PIT is problematic because the PIT may be necessary for udelay setup. Yes, can initialise loops_per_jiffy conservatively. Just didn't quite get why you guys are talking about an ISA bus speed parameter. If the ISA bus is below 8 MHz, we might need a longer delay. If we default to the longer delay, the delay will be too long for more than 99,99 % of all systems, not counting i586+. Especially if the driver is fine-tuned to give maximum throughput, this may be bad. Yes, and I repeat -- old legacy ISA drivers can stay as they are. They've been doing what they've been doing for 15 years and given that the systems that break don't use them there is no practical upside to changing them and a big downside particularly with respect to difficulty of testing. A somewhat overly long delay shouldn't be particularly problematic for the few remaining legacy hardware users _outside_ drivers/ 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: provide a DMI based port 0x80 I/O delay override.
On 08-01-08 00:24, H. Peter Anvin wrote: Rene Herman wrote: Is this only about the ones then left for things like legacy PIC and PIT? Does anyone care about just sticking in a udelay(2) (or 1) there as a replacement and call it a day? PIT is problematic because the PIT may be necessary for udelay setup. Yes, can initialise loops_per_jiffy conservatively. Just didn't quite get why you guys are talking about an ISA bus speed parameter. Rene. 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: provide a DMI based port 0x80 I/O delay override.
On 07-01-08 23:27, Bodo Eggert wrote: On Mon, 7 Jan 2008, H. Peter Anvin wrote: There might have been a few 386/20's clocking the ISA bus at ÂÂ÷3 (6.67 MHz) rather than ÷2 (10 MHz) or ÷2.5 (8 MHz). Yes, and the remaining users should set the kernel option. Both of them. The question is: How will they be told about the new kernel option? What exactly are you guys still talking about? Alan is looking at drivers and finds that in them outb_p is generally correct and correctly specified in bus-clocks for at least some (8390 was quoted). In those legacy drivers, the _p ops can simply stay and can use the 15-year old proven 0x80 outb. (with molnar suggesting they be renamed isa_in/outb_p and me suggesting that if someone would be doing _that_ they might as well split them manually in outb(); slow_down_io() possibly renaming slow_down_io() to isa_io_delay() or similar). Is this only about the ones then left for things like legacy PIC and PIT? Does anyone care about just sticking in a udelay(2) (or 1) there as a replacement and call it a 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: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On 02-01-08 16:35, Rene Herman wrote:
> On 02-01-08 14:47, Alan Cox wrote:
>
>>> ok, you are right. How about we go with one of your suggestions:
>>> rename the API family to isa_*_p() in the affected ISA drivers? That
>>> makes it perfectly clear that this is an ISA related historic quirk
>>> that we just cannot properly emulate in an acceptable fashion. It
>>> will also make the least amount of changes to these truly historic
>>> drivers.
>>
>> Works for me. We need to build two versions of 8390.c now but thats no
>> big deal and sorts PCMCIA out too.
>
> For no binary changes at all, and if going through all those outb_p()
> users anyway, might/could as well just manually split them then:
>
> outb_p() --> outb();
> slow_down_io();
>
> and then just leave out the slow_down_io() call in the non-ISA spots.
> slow_down_io() could be renamed isa_io_delay() or anything (paravirt is
> a little annoying there) if someone cares but then it's a complete
> identity transformation for any driver that does care.
>
> Would IMO also make for a somewhat better API than an isa_outb_p() as
> there's nothing particurly ISA about the outb method itself -- many ISA
> drivers use plain outb() as well.
Would just need this bit of io.h arch unification from the orignal patch and
that's it:
diff --git a/include/asm-x86/io_64.h b/include/asm-x86/io_64.h
index a037b07..97cb8c6 100644
--- a/include/asm-x86/io_64.h
+++ b/include/asm-x86/io_64.h
@@ -35,13 +35,20 @@
* - Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
*/
-#define __SLOW_DOWN_IO "\noutb %%al,$0x80"
+static inline void native_io_delay(void)
+{
+ asm volatile("outb %%al,$0x80" : : : "memory");
+}
+static inline void slow_down_io(void)
+{
+ native_io_delay();
#ifdef REALLY_SLOW_IO
-#define __FULL_SLOW_DOWN_IO __SLOW_DOWN_IO __SLOW_DOWN_IO __SLOW_DOWN_IO
__SLOW_DOWN_IO
-#else
-#define __FULL_SLOW_DOWN_IO __SLOW_DOWN_IO
+ native_io_delay();
+ native_io_delay();
+ native_io_delay();
#endif
+}
/*
* Talk about misusing macros..
@@ -50,21 +57,21 @@
static inline void out##s(unsigned x value, unsigned short port) {
#define __OUT2(s,s1,s2) \
-__asm__ __volatile__ ("out" #s " %" s1 "0,%" s2 "1"
+__asm__ __volatile__ ("out" #s " %" s1 "0,%" s2 "1" : : "a" (value), "Nd"
(port))
#define __OUT(s,s1,x) \
-__OUT1(s,x) __OUT2(s,s1,"w") : : "a" (value), "Nd" (port)); } \
-__OUT1(s##_p,x) __OUT2(s,s1,"w") __FULL_SLOW_DOWN_IO : : "a" (value), "Nd"
(port));} \
+__OUT1(s,x) __OUT2(s,s1,"w"); } \
+__OUT1(s##_p,x) __OUT2(s,s1,"w"); slow_down_io(); }
#define __IN1(s) \
static inline RETURN_TYPE in##s(unsigned short port) { RETURN_TYPE _v;
#define __IN2(s,s1,s2) \
-__asm__ __volatile__ ("in" #s " %" s2 "1,%" s1 "0"
+__asm__ __volatile__ ("in" #s " %" s2 "1,%" s1 "0" : "=a" (_v) : "Nd" (port))
-#define __IN(s,s1,i...) \
-__IN1(s) __IN2(s,s1,"w") : "=a" (_v) : "Nd" (port) ,##i ); return _v; } \
-__IN1(s##_p) __IN2(s,s1,"w") __FULL_SLOW_DOWN_IO : "=a" (_v) : "Nd" (port)
,##i ); return _v; } \
+#define __IN(s,s1) \
+__IN1(s) __IN2(s,s1,"w"); return _v; } \
+__IN1(s##_p) __IN2(s,s1,"w"); slow_down_io(); return _v; }
#define __INS(s) \
static inline void ins##s(unsigned short port, void * addr, unsigned long
count) \
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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: provide a DMI based port 0x80 I/O delay override.
On 02-01-08 14:47, Alan Cox wrote: ok, you are right. How about we go with one of your suggestions: rename the API family to isa_*_p() in the affected ISA drivers? That makes it perfectly clear that this is an ISA related historic quirk that we just cannot properly emulate in an acceptable fashion. It will also make the least amount of changes to these truly historic drivers. Works for me. We need to build two versions of 8390.c now but thats no big deal and sorts PCMCIA out too. For no binary changes at all, and if going through all those outb_p() users anyway, might/could as well just manually split them then: outb_p() --> outb(); slow_down_io(); and then just leave out the slow_down_io() call in the non-ISA spots. slow_down_io() could be renamed isa_io_delay() or anything (paravirt is a little annoying there) if someone cares but then it's a complete identity transformation for any driver that does care. Would IMO also make for a somewhat better API than an isa_outb_p() as there's nothing particurly ISA about the outb method itself -- many ISA drivers use plain outb() as well. 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: provide a DMI based port 0x80 I/O delay override
On 31-12-07 16:56, Alan Cox wrote: Okay. Am about to go stuff my face with new years celebrations but will definitely try to make that old WD8003 hickup. Have fun. Is it an 8390 or an 83905 ? A DP8390BN. And I have a DP8390CN on a 3Com Etherlink II. The NE1000 has a DP83901AV, my new-fangled Networth combo WD/NE cards DP83905s. 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: provide a DMI based port 0x80 I/O delay override.
On 02-01-08 01:55, Christer Weinigel wrote: On Wed, 02 Jan 2008 00:11:54 +0100 Rene Herman <[EMAIL PROTECTED]> wrote: Well, on the PIIX it is and I guess on anything where it's _not_ fully internal an 0xf0 write wouldn't have any effect on IRQ13... When you earlier mentioned this it seemed 0xed switched on DMI would be good enough, but well. Alan, do you have an opinion on the port 0xf0 write? It should probably still be combined with a replacement/deletion for new machines due to the bus-locking "bad for real-time" thing you mentioned earlier but in the short run it could be a fairly low-impact replacement on anything except a 386+387 Both 0xed and 0xf0 are mapped to internal functions on the AMD Elan SC400 processor. It is an AMD 486 based system on a chip and since AMD just knew that it would never have a math coprocessor, they reused the 0xf0-0xf2 range for the PCMCIA controller. I guess the AMD Elan SC500 will have similar problems. I seem to recall that back when I was working with the Elan SC400 (sometime around 1998?) there were discussions about finding an alternate delay port because outb to 0x80 messed up the debug port. I think the Elan stopped those discussions because just about every port on the Elan was reused for some alternate purpose. Okay, thanks much. So 0xf0 would be unuseable on 386+387 and AMD Elan SC400 and could possibly change timing on an unknown number of systems due to not being put on the bus. 0x80 only fails for some recent HP laptops instead so it seems there would be not enough cause to go with 0xf0 onstead of 0x80 as the default choice; if we're quirking around machines anyway it might as well be the DMI based quirking currently suggested. 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: provide a DMI based port 0x80 I/O delay override.
On 02-01-08 00:11, Rene Herman wrote: On 01-01-08 23:39, H. Peter Anvin wrote: Yes, we do. It's exactly this side effect which makes this safer than either 0x80 or 0xED -- it's a port that *guaranteed* can't be reclaimed for other purposes without breaking MS-DOS compatibility. I see that with CR0.NE set (*) we indeed don't care about IGNNE#... However, I'm worried about this comment in arch/x86/kernel/i8259_32.c === /* * New motherboards sometimes make IRQ 13 be a PCI interrupt, * so allow interrupt sharing. */ === Is it really safe to just blindly negate IRQ13 on everything out there, from regular PC through funky embedded thingies? It's not any IRQ 13, it's IRQ 13 from the FPU. Well, on the PIIX it is and I guess on anything where it's _not_ fully internal an 0xf0 write wouldn't have any effect on IRQ13... When you earlier mentioned this it seemed 0xed switched on DMI would be good enough, but well. Alan, do you have an opinion on the port 0xf0 write? It should probably still be combined with a replacement/deletion for new machines due to the bus-locking "bad for real-time" thing you mentioned earlier but in the short run it could be a fairly low-impact replacement on anything except a 386+387 We should do a another timing measurement survey and it makes for sligtly worse code if we indeed feel it's not safe enough to write anything other than 0, but otherwise it's quite minimal. Thinking about this, my main worry about 0xf0 as a 0x80 replacement would be systems that have elected to _not_ let port 0xf0 writes flow through to ISA changing the timing-characteristics. Given that it's a known port, someone may have elected to just keep it fully internal. Upto now the datasheets I've read do put it on ISA... 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: provide a DMI based port 0x80 I/O delay override.
On 01-01-08 23:39, H. Peter Anvin wrote: Yes, we do. It's exactly this side effect which makes this safer than either 0x80 or 0xED -- it's a port that *guaranteed* can't be reclaimed for other purposes without breaking MS-DOS compatibility. I see that with CR0.NE set (*) we indeed don't care about IGNNE#... However, I'm worried about this comment in arch/x86/kernel/i8259_32.c === /* * New motherboards sometimes make IRQ 13 be a PCI interrupt, * so allow interrupt sharing. */ === Is it really safe to just blindly negate IRQ13 on everything out there, from regular PC through funky embedded thingies? It's not any IRQ 13, it's IRQ 13 from the FPU. Well, on the PIIX it is and I guess on anything where it's _not_ fully internal an 0xf0 write wouldn't have any effect on IRQ13... When you earlier mentioned this it seemed 0xed switched on DMI would be good enough, but well. Alan, do you have an opinion on the port 0xf0 write? It should probably still be combined with a replacement/deletion for new machines due to the bus-locking "bad for real-time" thing you mentioned earlier but in the short run it could be a fairly low-impact replacement on anything except a 386+387 We should do a another timing measurement survey and it makes for sligtly worse code if we indeed feel it's not safe enough to write anything other than 0, but otherwise it's quite minimal. 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: provide a DMI based port 0x80 I/O delay override.
On 01-01-08 22:44, H. Peter Anvin wrote:
Rene Herman wrote:
On 01-01-08 22:15, H. Peter Anvin wrote:
I have mentioned this before... I think writing zero to port 0xf0
would be an acceptable pause interface (to the extent where we need
an I/O port) except on 386 with 387 present; on those systems we can
fall back to 0x80.
PII 400 / Intel 440 BX (PIIX4):
[EMAIL PROTECTED]:~/port80$ su -c ./portime
out 0x80: 544 cycles
in 0x80: 254 cycles
in 0x61: 254 cycles
out 0xf0: 544 cycles
The Intel PIIX/PIIX3 datasheet specifically mentions that both reads
and writes at 0xf0 "flow through to the ISA bus".
However, more complete, it says:
"Writing to this register causes the PIIX/PIIX3 to assert IGNNE#. The
PIIX/PIIX3 also negates IRQ13 (internal to the PIIX). Note that IGNNE#
is not asserted unless FERR# is active. Reads/writes flow through to
the ISA bus".
We don't want the side-effects, do we?
Yes, we do. It's exactly this side effect which makes this safer than
either 0x80 or 0xED -- it's a port that *guaranteed* can't be reclaimed
for other purposes without breaking MS-DOS compatibility.
I see that with CR0.NE set (*) we indeed don't care about IGNNE#...
However, I'm worried about this comment in arch/x86/kernel/i8259_32.c
===
/*
* New motherboards sometimes make IRQ 13 be a PCI interrupt,
* so allow interrupt sharing.
*/
===
Is it really safe to just blindly negate IRQ13 on everything out there, from
regular PC through funky embedded thingies?
(*) bit 5:
[EMAIL PROTECTED]:~/src/local$ ./smsw
msw: 0x3b
Rene.
/* gcc -W -Wall -o smsw smsw.c */
#include
#include
int main(void)
{
uint16_t msw;
asm ("smsw %0": "=r" (msw));
printf("msw: %#hx\n", msw);
return 0;
}
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On 01-01-08 22:42, Christer Weinigel wrote: The data sheet for the Intel M8259A says: End of /RD to Next Command: 300 ns End of /WR to Next Command: 370 ns On the other hand, I don't know how all the i8253/i8259 clones or the numerous variants of Super I/O chips behave. It wouldn't surprise me if some Super I/O chip uses the ISA bus clock to latch the values internally so that the delay is dependent on the bus frequency instead. I wouldn't even be surprised if most all would... 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: provide a DMI based port 0x80 I/O delay override.
On 01-01-08 22:15, H. Peter Anvin wrote:
I have mentioned this before... I think writing zero to port 0xf0 would
be an acceptable pause interface (to the extent where we need an I/O
port) except on 386 with 387 present; on those systems we can fall back
to 0x80.
PII 400 / Intel 440 BX (PIIX4):
[EMAIL PROTECTED]:~/port80$ su -c ./portime
out 0x80: 544 cycles
in 0x80: 254 cycles
in 0x61: 254 cycles
out 0xf0: 544 cycles
The Intel PIIX/PIIX3 datasheet specifically mentions that both reads and
writes at 0xf0 "flow through to the ISA bus".
However, more complete, it says:
"Writing to this register causes the PIIX/PIIX3 to assert IGNNE#. The
PIIX/PIIX3 also negates IRQ13 (internal to the PIIX). Note that IGNNE# is
not asserted unless FERR# is active. Reads/writes flow through to the ISA bus".
We don't want the side-effects, do we?
Rene.
/* gcc -W -Wall -O2 -o portime portime.c */
#include
#include
#include
#include
#define LOOPS 1
inline uint64_t rdtsc(void)
{
uint32_t hi, lo;
asm ("rdtsc": "=d" (hi), "=a" (lo));
return (uint64_t)hi << 32 | lo;
}
inline void serialize(void)
{
asm ("cpuid": : : "eax", "ebx", "ecx", "edx");
}
int main(void)
{
uint64_t tsc0, tsc1, tsc2, tsc3, tsc4, tsc5;
uint64_t out80, in80, in61, outf0;
int i;
if (iopl(3) < 0) {
perror("iopl");
return EXIT_FAILURE;
}
asm ("cli");
tsc0 = rdtsc();
for (i = 0; i < LOOPS; i++) {
serialize();
serialize();
}
tsc1 = rdtsc();
for (i = 0; i < LOOPS; i++) {
serialize();
asm ("outb %al, $0x80");
serialize();
}
tsc2 = rdtsc();
for (i = 0; i < LOOPS; i++) {
serialize();
asm ("inb $0x80, %%al": : : "al");
serialize();
}
tsc3 = rdtsc();
for (i = 0; i < LOOPS; i++) {
serialize();
asm ("inb $0x61, %%al": : : "al");
serialize();
}
tsc4 = rdtsc();
for (i = 0; i < LOOPS; i++) {
serialize();
asm ("outb %b0, $0xf0": : "a" (0));
serialize();
}
tsc5 = rdtsc();
asm ("sti");
out80 = ((tsc2 - tsc1) - (tsc1 - tsc0)) / LOOPS;
in80 = ((tsc3 - tsc2) - (tsc1 - tsc0)) / LOOPS;
in61 = ((tsc4 - tsc3) - (tsc1 - tsc0)) / LOOPS;
outf0 = ((tsc5 - tsc4) - (tsc1 - tsc0)) / LOOPS;
printf("out 0x80: %llu cycles\n", out80);
printf("in 0x80: %llu cycles\n", in80);
printf("in 0x61: %llu cycles\n", in61);
printf("out 0xf0: %llu cycles\n", outf0);
return EXIT_SUCCESS;
}
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On 01-01-08 20:35, Christer Weinigel wrote: On Tue, 1 Jan 2008 19:46:59 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote: * Christer Weinigel <[EMAIL PROTECTED]> wrote: What I'm afraid is that udelay will be significantly slower, [...] why should it be significantly slower? out 80h, al is only two bytes. Any alternative that has been suggested in this discussion will use more space. mov dx, alt_port; out dx, al will be larger, a function call will definitely be a lot larger. People have been making changes to the kernel to save a couple of hundred bytes of text size. On old hardware (or anything with an ISA bus which I'd guess includes the Geode SCx200 SoC which is basically a MediaGX processor, a southbridge and an ISA bus with a Super I/O chip on it) an out to 80h will use exactly one ISA cycle. Not to disagree with the point but more like 8 (1 us at 8 MHz). It's the timeout property. A call to udelay will need a margin, so it will be slightly slower. And that's assuming that you can find out the speed of the ISA bus, if you can't you'll have to assume the slowest possible bus (6 MHz I guess) which will be a lot slower. I don't know if the difference in code size or the udelay will be significantly slower, but I think it might be. There's also the bit about microseconds being very losely defined pre loops_per_jiffy calibration. Per CPU-family init helps somewhat but certainly for family 6 (Pentium Pro, II, III -- lots of hardware with ISA busses therefore) speeds vary quite a bit still. And to take the MediaGX as an example, the TSC is not usable on that CPU, so Linux has to use the PIT timer for gettimeofday. As I wrote in a different post, I believe the PIT on the SCx200 needs outb_p to work reliably. So if outb_p becomes significantly slower that will affect a critical path on a very common embedded CPU. I'm not sure what Alan meant with his comments about locking, but if changing outb_p to use an udelay means that we have to add locking, that is also going to affect the code size and speed. Explained here: http://lkml.org/lkml/2007/12/30/136 However, that's not an argument. Missing locking is a bug, and current outb I/O delay use hiding it doesn't change that. 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: provide a DMI based port 0x80 I/O delay override
On 31-12-07 13:23, Alan Cox wrote:
I dug out the reference drivers. The reference drivers use the delay and
the 8390 datasheet confirms it is neccessary.
Great, thanks for that.
The Crynwr driver has some interesting things to say
| The National 8390 Chip (NIC) requires 4 bus clocks between successive
| chip selects (National DP8390 Data Sheet Addendum, June 1990)
Okay, that's pretty specific. Given that these things exist on actual ISA
cards and "I/O recovery time" BIOS settings that are availabe also on these
old 386s already it's probably still at least somewhat debatable how much
linux drivers really need to care even in this case -- but let's ignore that.
Also " To establish a minimum delay, an I/O instruction must be used. A
good rule of ; thumb is that ISA I/O instructions take ~1.0 microseconds
and MCA I/O ; instructions take ~0.5 microseconds. Reading the NMI Status
Register (0x61) ; is a good way to pause on all machines."
But all the official drivers use pauses and the manual says they are
needed for correct, reliable behaviour - at least with a genuine 8390.
Okay. Am about to go stuff my face with new years celebrations but will
definitely try to make that old WD8003 hickup.
By the way, expected, but before anyone else mentions it -- no, reading from
port 0x61 is not a reliable delay today. Duron 1300 / AMD756:
[EMAIL PROTECTED]:~/src/port80$ su -c ./portime
out 0x80: 2400 cycles
in 0x80: 2400 cycles
in 0x61: 2400 cycles
But PII 400 / Intel 440BX:
[EMAIL PROTECTED]:~/port80$ su -c ./portime
out 0x80: 545 cycles
in 0x80: 254 cycles
in 0x61: 254 cycles
Rene.
/* gcc -W -Wall -O2 -o portime portime.c */
#include
#include
#include
#include
#define LOOPS 1
inline uint64_t rdtsc(void)
{
uint32_t hi, lo;
asm ("rdtsc": "=d" (hi), "=a" (lo));
return (uint64_t)hi << 32 | lo;
}
inline void serialize(void)
{
asm ("cpuid": : : "eax", "ebx", "ecx", "edx");
}
int main(void)
{
uint64_t tsc0, tsc1, tsc2, tsc3, tsc4;
uint64_t out, in8, in6;
int i;
if (iopl(3) < 0) {
perror("iopl");
return EXIT_FAILURE;
}
asm ("cli");
tsc0 = rdtsc();
for (i = 0; i < LOOPS; i++) {
serialize();
serialize();
}
tsc1 = rdtsc();
for (i = 0; i < LOOPS; i++) {
serialize();
asm ("outb %al, $0x80");
serialize();
}
tsc2 = rdtsc();
for (i = 0; i < LOOPS; i++) {
serialize();
asm ("inb $0x80, %%al": : : "al");
serialize();
}
tsc3 = rdtsc();
for (i = 0; i < LOOPS; i++) {
serialize();
asm ("inb $0x61, %%al": : : "al");
serialize();
}
tsc4 = rdtsc();
asm ("sti");
out = ((tsc2 - tsc1) - (tsc1 - tsc0)) / LOOPS;
in8 = ((tsc3 - tsc2) - (tsc1 - tsc0)) / LOOPS;
in6 = ((tsc4 - tsc3) - (tsc1 - tsc0)) / LOOPS;
printf("out 0x80: %llu cycles\n", out);
printf("in 0x80: %llu cycles\n", in8);
printf("in 0x61: %llu cycles\n", in6);
return EXIT_SUCCESS;
}
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
On 30-12-07 22:44, H. Peter Anvin wrote:
Ingo Molnar wrote:
It probably should actually HLT, to avoid sucking power, and
stressing the thermal system. We're dead at this point, and the
early 486's which had problems with HLT will lock up - we don't care.
ok. Like the patch below?
Don't need the cli; we're already running with interrupts disabled.
I'd do:
while (1)
asm volatile("hlt");
... mostly on general principles.
At least with current GCC the volatile isn't strictly needed as its implied
without output operands but I was only certain after checking that. Do you
remember if that used to be different for previous GCC versions? I tend to
also stick volatiles on them still...
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: provide a DMI based port 0x80 I/O delay override
On 30-12-07 21:46, Ingo Molnar wrote: * Alan Cox <[EMAIL PROTECTED]> wrote: So the current plan is to go with an io_delay=udelay default in v2.6.25, to give this a migration window, and io_delay=none in v2.6.26 [and a complete removal of arch/x86/kernel/io_delay.c], once the _p() uses are fixed up. This is gradual enough to notice any regressions we care about and also makes it nicely bisectable and gradual. You will break systems if you blindly go around disabling _p delays for ISA and LPC bus devices. The DEC Hinote laptops for example are well known for requiring the correct ISA and other keyboard controller delays. I don't expect anyone to test with a hinote or see it until it hits Debian or similar 'low resource' friendly devices. well, using io_delay=udelay is not 'blindly disabling'. On the other hand, the patch you just posted that makes io_delay=none the default _is_ blindly disabling. So that wasn't for consumption? io_delay=udelay additionally blindly disables the race-hiding effect the outb has on SMP and that Alan is seeing so many of. Should also wait for more driver review. 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] Option to disable AMD C1E (allows dynticks to work)
On 29-12-07 10:09, Richard Harman wrote: Anyway, I'm extremely open to getting to the bottom of working around the quirks on this hardware. If I havn't mentioned it previously, this laptop is an HP dv6408nr, with an amd turion tl-56 cpu and nVidia MCP51 chipset. What can I do to help? It has been pulling teeth trying to get to the bottom of this. This thread-branch appears to be broken on lkml.org so I couldn't look back through it but was this what you tried? http://lkml.org/lkml/2007/12/29/65 Updated patch with Islam's values added at: http://lkml.org/lkml/2007/12/29/141 You'd plug in your values similarly and test... 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: provide a DMI based port 0x80 I/O delay override
On 30-12-07 21:00, Linus Torvalds wrote: On Sun, 30 Dec 2007, Rene Herman wrote: I also just now dug up a "WDC (C) 1987" WD8003EBT and a "Novell, Inc (C) 1990" NE1000, both 8-bit ISA NICs and the ownership of which, I would suggest, makes me a really cool person. .. I'm also told that mentioning this is a really good way to pick up any hot chicks in singles bars. "If you've got it, flaunt it". Please let us know how it turns out for you, Ah, check, thanks, will do! 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: provide a DMI based port 0x80 I/O delay override
On 30-12-07 19:39, Alan Cox wrote: On Sun, 30 Dec 2007 19:14:40 +0100 Rene Herman <[EMAIL PROTECTED]> wrote: I'm by the way looking at drivers/net/wd.c which my 386 uses for its dual mode NE2000/WD8013 clone ISA NIC and while it specifically needs no delay at all it seems, the mixed use of out and outb_p seems to suggest that someone once thought about that. Would you advice sticking in a udelay(2) manually there? I would need to dig out the documentation and NE2000 reference code if I even still have them. From memory NE2K needs them but I don't know offhand if the WD80x3 devices do, or if only some of them do. It'll also depend on the port - the DPRAM is different to the 8390. Don Becker wrote the drivers and at the time he tuned them carefully for performance so I would expect delays to be the ones needed This NIC (a Networth UTP16B) has a National Semiconductor DP83905 AT/LANTIC for which I'm reading the software developers guide now. It doesn't seem to list specific delays... I also just now dug up a "WDC (C) 1987" WD8003EBT and a "Novell, Inc (C) 1990" NE1000, both 8-bit ISA NICs and the ownership of which, I would suggest, makes me a really cool person. Both are coax and a little clumsy to test but that 1987 one is probably going to be close to the oldest type around. I've been testing with the 386's own 2.2.26 kernel upto now but I'll try and compile a 2.6 system on there with uclibc and busybox or some such and test more. 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: provide a DMI based port 0x80 I/O delay override
On 30-12-07 17:48, Alan Cox wrote: For processors with TSC I think we should aim for 2.6.25 to do this and to have the major other _p fixups done. I pity whoever does stuff like the scc drivers but most of the rest isn't too bad. I'm by the way looking at drivers/net/wd.c which my 386 uses for its dual mode NE2000/WD8013 clone ISA NIC and while it specifically needs no delay at all it seems, the mixed use of out and outb_p seems to suggest that someone once thought about that. Would you advice sticking in a udelay(2) manually there? 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: provide a DMI based port 0x80 I/O delay override
On 30-12-07 18:06, Ingo Molnar wrote: * Rene Herman <[EMAIL PROTECTED]> wrote: Real ISA systems will also generally respond faster to it than the unused port (this thing actually has an ISA bus but not VGA on it ofcourse) which means that "a perfect delay register" it is not. But yes, I have an actual Am386DX-40 with ISA VGA up and running which also doesn't care either way, about the ones in misc_32.c or anywhere else for that matter. yeah - and that's typical of most _p() use: most of them are totally bogus, but the global existence of the delay was used as a "it _might_ break system" boogey-man against replacing it. No delaying at all does break a few systems. so _IF_ we do any delay in x86 platform drivers, we at most do a delay on the order of the round-trip latency to the same piece of hardware we are handling. Given that part of the problem is 2 MHz devices on a 8 MHz bus, you can't do this generally. 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: provide a DMI based port 0x80 I/O delay override
On 30-12-07 17:07, Ingo Molnar wrote: * Rene Herman <[EMAIL PROTECTED]> wrote: On 30-12-07 16:28, Ingo Molnar wrote: hardware. (which makes it a perfect delay register in any case) Hardly. Duron 1300 on AMD756: but that does not matter at all: that's not '90s era hardware that we are (slightly) worried about wrt. IO delays in misc_32.c. (i.e. on _real_ ISA systems) Real ISA systems will also generally respond faster to it than the unused port (this thing actually has an ISA bus but not VGA on it ofcourse) which means that "a perfect delay register" it is not. But yes, I have an actual Am386DX-40 with ISA VGA up and running which also doesn't care either way, about the ones in misc_32.c or anywhere else for that matter. Me myself never having seen anything actually care since using that machine actively was in fact the reason I got involved so don't get me wrong; doing away with 0x80 use would be quite sensible. It's just that various machines that _do_ need it (and which were reported to exist) are by now gathering dust in basements and will not timely respond/test this. Which, again, also means their possible regression might not be considered all that regressive but still; if x86 should support anything under the sun still it's a sensible worry. 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: provide a DMI based port 0x80 I/O delay override
On 30-12-07 16:28, Ingo Molnar wrote: Reading from the 0x3cc port does not impact the cursor position update sequence IIRC - i think the vidport is even ignored for the input direction by most hardware, there's a separate input register. The 0x3cc port is a well-defined VGA register which should be unused on non-VGA hardware. (which makes it a perfect delay register in any case) Hardly. Duron 1300 on AMD756: [EMAIL PROTECTED]:~/src/port80$ su -c ./port80 cycles: out 2400, in 2401 [EMAIL PROTECTED]:~/src/port80$ su -c ./port3cc cycles: out 459, in 394 As stated a few dozen times by now already, port 0x80 is _decidedly_ _non_ _random_ 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: provide a DMI based port 0x80 I/O delay override
On 30-12-07 10:30, Linus Torvalds wrote: On Sun, 30 Dec 2007, Rene Herman wrote: This fixes "hwclock" triggered boottime hangs for a few HP/Compaq laptops and might as such be applicable to 2.6.24 still. It's not a regression as far as I can see (ie we've always done that port 80 access for slow-down), and quite frankly, I think the code is horribly ugly. It is indeed not a regression. Submitted it as a stop-gap measure for those specific afflicted machines but I guess they'll mostly be able to google up the problem and patch by now as well.. Using a DMI quirk for something like this is just not maintainable. Are we going to live with doing new quirks forever? I'd rather just remove the slowdown entirely (obviously that is not for 2.6.24 either, though!), and drivers that then are shown to really need it could use their *own* ports. And yes, "elegant" it is neither. It's a bit of a pesky problem though. Port 0x80 is a decidedly non-random port selection in so far that it's just about the only available port with guaranteed (in a PC sense) effects -- various chipsets make specific efforts to forward port 0x80 writes onto ISA due to its use as a POST port by the PC BIOS meaning the outb outside its bus-level effects also has fairly well defined timing characteristics. In practice, a udelay(2) is going to satisfy the delay property though -- but doesn't do anything for the other things the outb() does. The legacy PIT, PIC and DMA and KB controllers have been mentioned in this and previous incarnations of this same thread as hardware that in some implementations need the outb to function properly but ofcourse, no _sane_ implementations do. With an arch that purports to support just about anything though there's some fairly justified fear, uncertainty, doubt that the ones to break aren't going to be found and reported quickly/easily. In itself, that could mean it's also not something to be overly worried about, but still not nice. With the various races in (legacy) drivers additionally an early suggestion by Andi Kleen to leave the outb in place for a DMI year < X (or no DMI available) and just do nothing for > X might in fact be justified. 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/
[PATCH] x86: provide a DMI based port 0x80 I/O delay override
Hi Linus. [ resend, forgot the CC to linux-kernel. sorry ] This fixes "hwclock" triggered boottime hangs for a few HP/Compaq laptops and might as such be applicable to 2.6.24 still. The kernel's use of an outb to port 0x80 as an I/O delay disagrees with these machines (after ACPI is live, that is) and this provides for a DMI based switch to alternate port 0xed for them. Complete changelog inside the patch. An evolved version of this patch that also supplies udelay(2) and as I/O delay lives in the x86.git tree as well but Alan Cox suggested those choices shouldn't yet be provided as he's finding races in drivers on SMP without the bus-locking outb. As a minimal version I thought you might perhaps want to take this as a specific fix for the afflicted laptops for 2.6.24. H. Peter Anvin earlier agreed it would be minimal enough for that. It was tested on both of the afflicted machines the DMI strings cover and doesn't change anything on others by default. It also introduces a bootparam io_delay= to make (or override) the choice manually. Documentation/kernel-parameters.txt |6 ++ arch/x86/boot/compressed/misc_32.c |8 +-- arch/x86/boot/compressed/misc_64.c |8 +-- arch/x86/kernel/Makefile_32 |2 arch/x86/kernel/Makefile_64 |2 arch/x86/kernel/io_delay.c | 77 arch/x86/kernel/setup_32.c |2 arch/x86/kernel/setup_64.c |2 include/asm-x86/io_32.h |6 -- include/asm-x86/io_64.h | 27 +++- 10 files changed, 115 insertions(+), 25 deletions(-) Rene. commit b2a10c0b8e6c1c73b940e60fae4cbe9db9ca9e3b Author: Rene Herman <[EMAIL PROTECTED]> Date: Mon Dec 17 21:23:55 2007 +0100 x86: provide a DMI based port 0x80 I/O delay override. Certain (HP/Compaq) laptops experience trouble from our port 0x80 I/O delay writes. This patch provides for a DMI based switch to the "alternate diagnostic port" 0xed (as used by some BIOSes as well) for these. David P. Reed confirmed that using port 0xed works and provides a proper delay on his HP Pavilion dv9000z, Islam Amer comfirmed that it does so on a Compaq Presario V6000. Both are Quanta boards, type 30B9 and 30B7 respectively and are the (only) machines for which the DMI based switch triggers. HP Pavilion dv6000z is expected to also need this but its DMI info hasn't been verified yet. The symptoms of _not_ working are a hanging machine, with "hwclock" use being a direct trigger and therefore the bootup often hanging already on these machines. Earlier versions of this attempted to simply use udelay(2), with the 2 being a value tested to be a nicely conservative upper-bound with help from many on the linux-kernel mailinglist, but that approach has two problems. First, pre-loops_per_jiffy calibration (which is post PIT init while some implementations of the PIT are actually one of the historically problematic devices that need the delay) udelay() isn't particularly well-defined. We could initialise loops_per_jiffy conservatively (and based on CPU family so as to not unduly delay old machines) which would sort of work, but still leaves: Second, delaying isn't the only effect that a write to port 0x80 has. It's also a PCI posting barrier which some devices may be explicitly or implicitly relying on. Alan Cox did a survey and found evidence that additionally various drivers are racy on SMP without the bus locking outb. Switching to an inb() makes the timing too unpredictable and as such, this DMI based switch should be the safest approach for now. Any more invasive changes should get more rigid testing first. It's moreover only very few machines with the problem and a DMI based hack seems to fit that situation. An early boot parameter to make the choice manually (and override any possible DMI based decision) is also provided: io_delay=standard|alternate This does not change the io_delay() in the boot code which is using the same port 0x80 I/O delay but those do not appear to be a problem as tested by David P. Reed. He moreover reported that booting with "acpi=off" also fixed things and seeing as how ACPI isn't touched until after this DMI based I/O port switch leaving the ones in the boot code be is safe. This patch is partly based on earlier patches from Pavel Machek and David P. Reed. Signed-off-by: Rene Herman <[EMAIL PROTECTED]> Tested-by: David P. Reed <[EMAIL PROTECTED]> Tested-by: Islam Amer <[EMAIL PROTECTED]> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 33121d6..6948e25 100644 --- a/Documentatio
Re: [PATCH] Option to disable AMD C1E (allows dynticks to work)
On 30-12-07 02:49, Islam Amer wrote: Glad I could be of help. Sure please go ahead, I will keep testing this patch with upcoming git kernels, and report any problems. Thanks. I'll see if Linus wants it for 2.6.24 still. Could be minimal enough. So what I understand now is that AMD C1E state saves battery like dynticks, so we don't need dynticks ? That bit I haven't a clue about I'm afraid... 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] Option to disable AMD C1E (allows dynticks to work)
On 29-12-07 23:28, Islam Amer wrote:
Thanks for the detailed response.
I thought I had gotten to the bottom of my problems when I found that
udev workaround, I guess I was naive.
I did the two tests you described and they predictably caused the hard
hangs. I needed to run the port80 program only once to get the hard
hang.
The output of the dmidecode commands were :
Quanta
30B7
I applied the patch you provided ( luckily I am using 2.6.24-rc6-git3
kernel because I need the b43 driver ), added these values and compiled.
{
.callback = dmi_io_delay_port_alt,
.ident = "Compaq Presario v6000",
.matches= {
DMI_MATCH(DMI_BOARD_VENDOR, "Quanta"),
DMI_MATCH(DMI_BOARD_NAME, "30B7")
}
},
I was able to boot without the udev workaround and can now use hwclock
without hanging the system. In dmesg I can see this new line :
Thanks much for testing (and David -- thanks for asking). Updated patch
attached with this information. Compaq itself seems to spell the type with a
capital V so that's the only difference...
Can I add a "Tested-by: Islam Amer <[EMAIL PROTECTED]>" to this? (and David,
same for you with this address you're using in this thread?)
Rene.
commit 5f27525d3e796ae12e3186afe8ef0ec41af9e160
Author: Rene Herman <[EMAIL PROTECTED]>
Date: Mon Dec 17 21:23:55 2007 +0100
x86: provide a DMI based port 0x80 I/O delay override.
Certain (HP/Compaq) laptops experience trouble from our port 0x80
I/O delay writes. This patch provides for a DMI based switch to the
"alternate diagnostic port" 0xed (as used by some BIOSes as well)
for these.
David P. Reed confirmed that using port 0xed works and provides a
proper delay on his HP Pavilion dv9000z, Islam Amer comfirmed that
it does so on a Compaq Presario V6000. Both are Quanta boards, type
30B9 and 30B7 respectively and are the (only) machines for which
the DMI based switch triggers. HP Pavilion dv6000z is expected to
also need this but its DMI info hasn't been verified yet.
The symptoms of _not_ working are a hanging machine, with "hwclock"
use being a direct trigger and therefore the bootup often hanging
already on these machines.
Earlier versions of this attempted to simply use udelay(2), with the
2 being a value tested to be a nicely conservative upper-bound with
help from many on the linux-kernel mailinglist, but that approach has
two problems.
First, pre-loops_per_jiffy calibration (which is post PIT init while
some implementations of the PIT are actually one of the historically
problematic devices that need the delay) udelay() isn't particularly
well-defined. We could initialise loops_per_jiffy conservatively (and
based on CPU family so as to not unduly delay old machines) which
would sort of work, but still leaves:
Second, delaying isn't the only effect that a write to port 0x80 has.
It's also a PCI posting barrier which some devices may be explicitly
or implicitly relying on. Alan Cox did a survey and found evidence
that additionally various drivers are racy on SMP without the bus
locking outb.
Switching to an inb() makes the timing too unpredictable and as such,
this DMI based switch should be the safest approach for now. Any more
invasive changes should get more rigid testing first. It's moreover
only very few machines with the problem and a DMI based hack seems
to fit that situation.
An early boot parameter to make the choice manually (and override any
possible DMI based decision) is also provided:
io_delay=standard|alternate
This does not change the io_delay() in the boot code which is using
the same port 0x80 I/O delay but those do not appear to be a problem
as tested by David P. Reed. He moreover reported that booting with
"acpi=off" also fixed things and seeing as how ACPI isn't touched
until after this DMI based I/O port switch leaving the ones in the
boot code be is safe.
This patch is partly based on earlier patches from Pavel Machek and
David P. Reed.
Signed-off-by: Rene Herman <[EMAIL PROTECTED]>
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 33121d6..6948e25 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -785,6 +785,12 @@ and is between 256 and 4096 characters. It is defined in
the file
for translation below 32 bit and if not available
then look in the higher range.
+ io_delay= [X86-32,X86-64] I/O delay port
+ standard
+ Use th
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On 17-12-07 22:56, Ingo Molnar wrote: * Rene Herman <[EMAIL PROTECTED]> wrote: Signed-off-by: Rene Herman <[EMAIL PROTECTED]> hm, i see this as a step backwards from the pretty flexible patch that David already tested. (and which also passed a few hundred bootup tests on my x86 test-grid) Please see Alan's comment that udelay (and none) shouldn't yet be provided as a choice. It opens race windows in drivers even when it works in practice on most setups. The version with "udelay" and "none" is not minimal, not low risk and certainly not .24 material. huh? By default we still use port 0x80. Any udelay is non-default and needs the user to explicitly switch to it. But it enables us to debug any suspected drivers by asking testers to: "please try this driver with io_delay=udelay, does it still work fine?". So those extra options are quite sensible. If you have any real technical arguments against that then please let us know. Ingo, have lots of fun playing with yourself, but remove my sign off from anything with the udelay and none methods. 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: provide a DMI based port 0x80 I/O delay override.
On 17-12-07 22:40, H. Peter Anvin wrote: Rene Herman wrote: Well, yes, I guess that does make sense. It's back again. Named the choices "standard" and "alternate" again as I feel "0x80" and "0xed" suggest they're free values a bit too much but if anyone feels strongly about it, so be it. They ARE -- or really, should be, free values (0xeb and 0xf0 are other reasonable values, for example.) I was afraid someone would say that. Making a random port available is fine for testing purposes but a failry dangerous thing to do generally. For a minimal version at -rc4 time, I believe sticking with 0x80 and 0xed ie best. Lots of time during .25 to go wild... 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: provide a DMI based port 0x80 I/O delay override.
On 17-12-07 22:41, Ingo Molnar wrote: * Rene Herman <[EMAIL PROTECTED]> wrote: On 17-12-07 17:12, Alan Cox wrote: I don't think we should be offering udelay based delays at this point. There are a lot of drivers to fix first. This is just one trivial example I agree. This thread's too full of people calling this outb method a dumb hack. It's a well-known legacy PC thing and while in practice the udelay might be a functional replacement for a majority of cases (save the races you are finding) a delay proportional to the bus speed makes great sense certainly when talking to hardware that itself runs proportinal to the bus speed for example. So, really, how about just sticking in this minimal version for now? Only switches the port to 0xed based on DMI and is all that is needed to fix the actual problem. This should be minimal and no-risk enough that it could also go to .24 if people want it to. It'll fix a few HP laptops (I'll try and get/verify the dv6000z DMI strings as well). Ingo? Signed-off-by: Rene Herman <[EMAIL PROTECTED]> hm, i see this as a step backwards from the pretty flexible patch that David already tested. (and which also passed a few hundred bootup tests on my x86 test-grid) Please see Alan's comment that udelay (and none) shouldn't yet be provided as a choice. It opens race windows in drivers even when it works in practice on most setups. The version with "udelay" and "none" is not minimal, not low risk and certainly not .24 material. David tested this part of the patch just as well. Attached again (with the boot param) since I see I left in an extraneous 'Use the" in the kernel-parameters.txt file. Rene. commit c12c7a47b9af87e8d867d5aa0ca5c6bcdd2463da Author: Rene Herman <[EMAIL PROTECTED]> Date: Mon Dec 17 21:23:55 2007 +0100 x86: provide a DMI based port 0x80 I/O delay override. Certain (HP) laptops experience trouble from our port 0x80 I/O delay writes. This patch provides for a DMI based switch to the "alternate diagnostic port" 0xed (as used by some BIOSes as well) for these. David P. Reed confirmed that port 0xed works for him and provides a proper delay. The symptoms of _not_ working are a hanging machine, with "hwclock" use being a direct trigger. Earlier versions of this attempted to simply use udelay(2), with the 2 being a value tested to be a nicely conservative upper-bound with help from many on the linux-kernel mailinglist, but that approach has two problems. First, pre-loops_per_jiffy calibration (which is post PIT init while some implementations of the PIT are actually one of the historically problematic devices that need the delay) udelay() isn't particularly well-defined. We could initialise loops_per_jiffy conservatively (and based on CPU family so as to not unduly delay old machines) which would sort of work, but still leaves: Second, delaying isn't the only effect that a write to port 0x80 has. It's also a PCI posting barrier which some devices may be explicitly or implicitly relying on. Alan Cox did a survey and found evidence that additionally various drivers are racy on SMP without the bus locking outb. Switching to an inb() makes the timing too unpredictable and as such, this DMI based switch should be the safest approach for now. Any more invasive changes should get more rigid testing first. It's moreover only very few machines with the problem and a DMI based hack seems to fit that situation. An early boot parameter to make the choice manually (and override any possible DMI based decision) is also provided: io_delay=standard|alternate This does not change the io_delay() in the boot code which is using the same port 0x80 I/O delay but those do not appear to be a problem as tested by David P. Reed. He moreover reported that booting with "acpi=off" also fixed things and seeing as how ACPI isn't touched until after this DMI based I/O port switch leaving the ones in the boot code be is safe. The DMI strings from David's HP Pavilion dv9000z are in there already and we need to get/verify the DMI info from other machines with the problem, notably the HP Pavilion dv6000z. This patch is partly based on earlier patches from Pavel Machek and David P. Reed. Signed-off-by: Rene Herman <[EMAIL PROTECTED]> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 33121d6..6948e25 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -785,6 +785,12 @@ and is between 256 and 4096 characters. It is defined in the file for translation below 32 bit and if n
[PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On 17-12-07 21:57, H. Peter Anvin wrote: Rene Herman wrote: On 17-12-07 17:12, Alan Cox wrote: I don't think we should be offering udelay based delays at this point. There are a lot of drivers to fix first. This is just one trivial example I agree. This thread's too full of people calling this outb method a dumb hack. It's a well-known legacy PC thing and while in practice the udelay might be a functional replacement for a majority of cases (save the races you are finding) a delay proportional to the bus speed makes great sense certainly when talking to hardware that itself runs proportinal to the bus speed for example. So, really, how about just sticking in this minimal version for now? Only switches the port to 0xed based on DMI and is all that is needed to fix the actual problem. This should be minimal and no-risk enough that it could also go to .24 if people want it to. It'll fix a few HP laptops (I'll try and get/verify the dv6000z DMI strings as well). I think retaining the command-line option available is a good thing, though. If nothing else, it is something very quick we can ask other people to try if they seem to have similar problems. Well, yes, I guess that does make sense. It's back again. Named the choices "standard" and "alternate" again as I feel "0x80" and "0xed" suggest they're free values a bit too much but if anyone feels strongly about it, so be it. Other than that, this alternate-port patch is a low-impact patch not affecting hardware not on the blacklist, which makes it appropriate for 2.6.24 IMO. Signed-off-by: Rene Herman <[EMAIL PROTECTED]> commit c83008ff40e95f89407807cb122127c5444b3bc4 Author: Rene Herman <[EMAIL PROTECTED]> Date: Mon Dec 17 21:23:55 2007 +0100 x86: provide a DMI based port 0x80 I/O delay override. Certain (HP) laptops experience trouble from our port 0x80 I/O delay writes. This patch provides for a DMI based switch to the "alternate diagnostic port" 0xed (as used by some BIOSes as well) for these. David P. Reed confirmed that port 0xed works for him and provides a proper delay. The symptoms of _not_ working are a hanging machine, with "hwclock" use being a direct trigger. Earlier versions of this attempted to simply use udelay(2), with the 2 being a value tested to be a nicely conservative upper-bound with help from many on the linux-kernel mailinglist, but that approach has two problems. First, pre-loops_per_jiffy calibration (which is post PIT init while some implementations of the PIT are actually one of the historically problematic devices that need the delay) udelay() isn't particularly well-defined. We could initialise loops_per_jiffy conservatively (and based on CPU family so as to not unduly delay old machines) which would sort of work, but still leaves: Second, delaying isn't the only effect that a write to port 0x80 has. It's also a PCI posting barrier which some devices may be explicitly or implicitly relying on. Alan Cox did a survey and found evidence that additionally various drivers are racy on SMP without the bus locking outb. Switching to an inb() makes the timing too unpredictable and as such, this DMI based switch should be the safest approach for now. Any more invasive changes should get more rigid testing first. It's moreover only very few machines with the problem and a DMI based hack seems to fit that situation. An early boot parameter to make the choice manually (and override any possible DMI based decision) is also provided: io_delay=standard|alternate This does not change the io_delay() in the boot code which is using the same port 0x80 I/O delay but those do not appear to be a problem as tested by David P. Reed. He moreover reported that booting with "acpi=off" also fixed things and seeing as how ACPI isn't touched until after this DMI based I/O port switch leaving the ones in the boot code be is safe. The DMI strings from David's HP Pavilion dv9000z are in there already and we need to get/verify the DMI info from other machines with the problem, notably the HP Pavilion dv6000z. This patch is partly based on earlier patches from Pavel Machek and David P. Reed. Signed-off-by: Rene Herman <[EMAIL PROTECTED]> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 33121d6..ff66cf4 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -785,6 +785,13 @@ and is between 256 and 4096 characters. It is defined in the file for translation below 32 bit and if not available then look in the higher range
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
On 15-12-07 00:29, Alan Cox wrote: ?? Just initialize bogomips to 6GHz equivalent... and we are fine until 6GHz cpus come out. How long will that take to boot on a 386? Well the dumb approach to fix that would seem to be to initialise it to cpu->family 3 -> 50MHz 4 -> 300Mhz 5-> etc... By the way, you have a 300 MHz 486? I believe 3 -> 40, 4 -> 133, 5 -> 233 would be good? And I'm not really sure about the etc. P6 has a large range again... 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: provide a DMI based port 0x80 I/O delay override.
On 17-12-07 17:12, Alan Cox wrote: I don't think we should be offering udelay based delays at this point. There are a lot of drivers to fix first. This is just one trivial example I agree. This thread's too full of people calling this outb method a dumb hack. It's a well-known legacy PC thing and while in practice the udelay might be a functional replacement for a majority of cases (save the races you are finding) a delay proportional to the bus speed makes great sense certainly when talking to hardware that itself runs proportinal to the bus speed for example. So, really, how about just sticking in this minimal version for now? Only switches the port to 0xed based on DMI and is all that is needed to fix the actual problem. This should be minimal and no-risk enough that it could also go to .24 if people want it to. It'll fix a few HP laptops (I'll try and get/verify the dv6000z DMI strings as well). Ingo? Signed-off-by: Rene Herman <[EMAIL PROTECTED]> commit e5f4d11c2470550500e8d8b798d902f2fe07b5c4 Author: Rene Herman <[EMAIL PROTECTED]> Date: Mon Dec 17 21:23:55 2007 +0100 x86: provide a DMI based port 0x80 I/O delay override. Certain (HP) laptops experience trouble from our port 0x80 I/O delay writes. This patch provides for a DMI based switch to the "alternate diagnostic port" 0xed (as used by some BIOSes as well) for these. David P. Reed confirmed that port 0xed works for him and provides a proper delay. The symptoms of _not_ working are a hanging machine, with "hwclock" use being a direct trigger. Earlier versions of this attempted to simply use udelay(2), with the 2 being a value tested to be a nicely conservative upper-bound with help from many on the linux-kernel mailinglist, but that approach has two problems. First, pre-loops_per_jiffy calibration (which is post PIT init while some implementations of the PIT are actually one of the historically problematic devices that need the delay) udelay() isn't particularly well-defined. We could initialise loops_per_jiffy conservatively (and based on CPU family so as to not unduly delay old machines) which would sort of work, but still leaves: Second, delaying isn't the only effect that a write to port 0x80 has. It's also a PCI posting barrier which some devices may be explicitly or implicitly relying on. Alan Cox did a survey and found evidence that additionally various drivers are racy on SMP without the bus locking outb. Switching to an inb() makes the timing too unpredictable and as such, this DMI based switch should be the safest approach for now. Any more invasive changes should get more rigid testing first. It's moreover only very few machines with the problem and a DMI based hack seems to fit that situation. This does not change the io_delay() in the boot code which is using the same port 0x80 I/O delay but those do not appear to be a problem as tested by David P. Reed. He moreover reported that booting with "acpi=off" also fixed things and seeing as how ACPI isn't touched until after this DMI based I/O port switch leaving the ones in the boot code be is safe. The DMI strings from David's HP Pavilion dv9000z are in there already and we need to get/verify the DMI info from other machines with the problem, notably the HP Pavilion dv6000z. This patch is partly based on earlier patches from Pavel Machek and David P. Reed. Signed-off-by: Rene Herman <[EMAIL PROTECTED]> diff --git a/arch/x86/boot/compressed/misc_32.c b/arch/x86/boot/compressed/misc_32.c index b74d60d..288e162 100644 --- a/arch/x86/boot/compressed/misc_32.c +++ b/arch/x86/boot/compressed/misc_32.c @@ -276,10 +276,10 @@ static void putstr(const char *s) RM_SCREEN_INFO.orig_y = y; pos = (x + cols * y) * 2; /* Update cursor position */ - outb_p(14, vidport); - outb_p(0xff & (pos >> 9), vidport+1); - outb_p(15, vidport); - outb_p(0xff & (pos >> 1), vidport+1); + outb(14, vidport); + outb(0xff & (pos >> 9), vidport+1); + outb(15, vidport); + outb(0xff & (pos >> 1), vidport+1); } static void* memset(void* s, int c, unsigned n) diff --git a/arch/x86/boot/compressed/misc_64.c b/arch/x86/boot/compressed/misc_64.c index 6ea015a..43e5fcc 100644 --- a/arch/x86/boot/compressed/misc_64.c +++ b/arch/x86/boot/compressed/misc_64.c @@ -269,10 +269,10 @@ static void putstr(const char *s) RM_SCREEN_INFO.orig_y = y; pos = (x + cols * y) * 2; /* Update cursor position */ - outb_p(14, vidport); - outb_p(0xff & (pos >> 9), vidport+1); - outb_p(15, vidport); - outb_p(0xff & (pos >> 1), vidport+1); +
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
On 17-12-07 19:14, linux-os (Dick Johnson) wrote: Attached is a patch that changes the outs to ins on port 0x80. No, that isn't useful. Only a write is "guaranteed" to make ISA/LPC meaning the timing for a read varies wildly. See the in/out cycles results posted earlier. Was also reading the Intel PIIX(3) chiset datasheet today which specifically mentions that only writes flow through to ISA, reads do not. 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: provide a DMI based port 0x80 I/O delay override.
On 17-12-07 14:32, David P. Reed wrote: Rene Herman wrote: No, most definitely not. Having the user select udelay or none through the kernel config and then the kernel deciding "ah, you know what, I'll know better and use port access anyway" is _utterly_ broken behaviour. Software needs to listen to its master. When acting as an ordinary user, the .config is beyond my control (except on Gentoo). It is in control of the distro (Fedora, Ubuntu, ... but perhaps not Gentoo). I think the distro guys want a default behavior that is set in .config, with quirk overrides being done when needed. And of course the user in his/her boot params gets the final say. Yes, and when the user/distributor specifically selected udelay or none as an I/O delay method it makes no sense whatsoever to have the kernel override that again -- the DMI hack only fixes something for the default case, when _no_ specific choice had been made (which the current setup can't express but mine did). I feel particularly strongly (always) about that "listen to its master" bit. The kernel does not know better then whomever configured it, even when it does. 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: provide a DMI based port 0x80 I/O delay override.
On 17-12-07 14:31, Pavel Machek wrote:
On Mon 2007-12-17 14:22:26, Rene Herman wrote:
On 17-12-07 14:09, Ingo Molnar wrote:
-#ifndef CONFIG_UDELAY_IO_DELAY
-static int __init dmi_alternate_io_delay_port(const struct
dmi_system_id *id)
+static int __init dmi_io_delay_0xed_port(const struct dmi_system_id
*id)
{
- printk(KERN_NOTICE "%s: using alternate I/O delay port\n", id->ident);
- io_delay = alternate_io_delay;
+ printk(KERN_NOTICE "%s: using 0xed I/O delay port\n", id->ident);
+ io_delay_type = CONFIG_IO_DELAY_TYPE_0XED;
+
return 0;
}
This isn't correct. DMI shouldn't override the CONFIG choice or someone
with matching DMI will have a defective CONFIG option. That's why I put
all of it inside #ifndef.
no, the DMI quirk is just that: a quirk that makes boxes work. The DMI
quirk takes precedence over just about any .config default, except an
explicit boot-commandline override.
No, most definitely not. Having the user select udelay or none through the
kernel config and then the kernel deciding "ah, you know what, I'll know
better and use port access anyway" is _utterly_ broken behaviour. Software
needs to listen to its master.
That's what command line is for. Ingo is right here.
No. The kernel shouldn't provide defective config options.
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: provide a DMI based port 0x80 I/O delay override.
On 17-12-07 14:09, Ingo Molnar wrote:
-#ifndef CONFIG_UDELAY_IO_DELAY
-static int __init dmi_alternate_io_delay_port(const struct dmi_system_id *id)
+static int __init dmi_io_delay_0xed_port(const struct dmi_system_id *id)
{
- printk(KERN_NOTICE "%s: using alternate I/O delay port\n", id->ident);
- io_delay = alternate_io_delay;
+ printk(KERN_NOTICE "%s: using 0xed I/O delay port\n", id->ident);
+ io_delay_type = CONFIG_IO_DELAY_TYPE_0XED;
+
return 0;
}
This isn't correct. DMI shouldn't override the CONFIG choice or
someone with matching DMI will have a defective CONFIG option. That's
why I put all of it inside #ifndef.
no, the DMI quirk is just that: a quirk that makes boxes work. The DMI
quirk takes precedence over just about any .config default, except an
explicit boot-commandline override.
No, most definitely not. Having the user select udelay or none through the
kernel config and then the kernel deciding "ah, you know what, I'll know
better and use port access anyway" is _utterly_ broken behaviour. Software
needs to listen to its master.
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: provide a DMI based port 0x80 I/O delay override.
On 17-12-07 04:35, H. Peter Anvin wrote: Well, we probably should leave the possibility in to use 0x80 -- for one thing, we need to use 0x80 on 386, and there is always the possibility that the switch will have different timing properties on some or all machines. Note that this doesn't require that a machine actually implements port 0xf0 for FERR/IGNNE, it just requires that they don't use it for something else. I would be rather inclined to try using port 0xf0 by default as long as family > 3[*] (with fallback to port 0x80) at least experimentally (-mm). Possible timing differences would be what worry me. 0x80 is well-known for its delay purposes, and frankly, I dont believe that one type of machine having a problem, which may very well have to be categorized a possibly BIOS fixable bug, is enough ground for switching everyone over to a different port It's enough ground to look at not doing outputs at all AFAIC but that's more due to the outb being somewhat cheesy to start with which using a different port wouldn't change. But, on the other hand: We *might* even be able to use port 0xf0 unconditionally in the setup code, since we're not using the FPU there (the only FPU instructions in the setup code are there to detect the FPU.) One thing: although I believe most actual implementations of port 0xf0 implement it as a strobe alone (data is ignored), all documentation I've found, including "The Undocumented PC" specifically says "write 0x00 to this port." This *could* mean there are platforms which use other values than 0x00 for other hacks. The Intel PIIX/PIIX3 datasheet confirms that the data is of no consequence, but yes, most documentation talks about 0. The PIIX/PIIX3 datasheet also says that both reads and writes flow through to the ISA bus, while for port 0x80 only writes do, and reads do not. I do not know how universal that is, but _reading_ port 0xf0 might in fact be sensible then? And should even work on a 386/387 pair? (I have a 386/387 in fact, although I'd need to dig it up). Versus the out it has the al clobber disadvantage, but givne that we're by now seem to be talking about out of line switch() native_io_delays anyways, that's not much of a problem anymore... [*] The following statements are equivalent: - family > 3. - CR0.NE is settable. - EFLAGS.AC is settable. For the boot code, I gather (which could I suppose then also plug in the delay port in the zero page or somewhere for use by the kernel proper? I don't know how/if these bits communicate). But, well, _reading_ port 0xf0 sounds promising across the board and low risk replacement _if_ teh PIIX/PIIX3 behaviour is as guaranteed as the port 0x80 behaviour... 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: provide a DMI based port 0x80 I/O delay override.
On 17-12-07 11:57, Ingo Molnar wrote:
thanks Rene! I've added your patch to x86.git. I changed a few things
ontop of it, see the additional changelog and delta patch below.
"appropriated it", more. Definitely not going to forgive you for deleting
that comment.
void native_io_delay(void)
{
- io_delay();
+ switch (io_delay_type) {
That's the clumsy bit. native_io_delay() used to be an inline outb, now it's
a switch. Yes, sure, versus an indirect call it's not actually worse, except
as an uglification.
-#ifndef CONFIG_UDELAY_IO_DELAY
-static int __init dmi_alternate_io_delay_port(const struct dmi_system_id *id)
+static int __init dmi_io_delay_0xed_port(const struct dmi_system_id *id)
{
- printk(KERN_NOTICE "%s: using alternate I/O delay port\n", id->ident);
- io_delay = alternate_io_delay;
+ printk(KERN_NOTICE "%s: using 0xed I/O delay port\n", id->ident);
+ io_delay_type = CONFIG_IO_DELAY_TYPE_0XED;
+
return 0;
}
This isn't correct. DMI shouldn't override the CONFIG choice or someone with
matching DMI will have a defective CONFIG option. That's why I put all of it
inside #ifndef.
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: provide a DMI based port 0x80 I/O delay override.
On 17-12-07 03:05, H. Peter Anvin wrote: Incidentally, I had the thought earlier today that port 0xf0 might be a suitable delay port. It is used only by the 387-emulating-a-287 hack for IRQ 13, which Linux doesn't use on 486+. [EMAIL PROTECTED]:~/src/port80$ su -c ./port80 cycles: out 2400, in 2400 [EMAIL PROTECTED]:~/src/port80$ su -c ./portf0 cycles: out 2400, in 2400 (Duron 1300) I suppose you mean using it instead of port 0x80 always and not just as an alternate port? For the latter 0xed is alright I guess... 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: provide a DMI based port 0x80 I/O delay override.
On 17-12-07 03:04, H. Peter Anvin wrote: Rene Herman wrote: On 17-12-07 00:12, David P. Reed wrote: Rene Herman wrote: David: I've plugged in your DMI values in this. Could you perhaps test this to confirm that it works for you? Will test it by tomorrow morning. Might as well test the new version then. Ingo Molnar requested a few changes and this fixes a couple of problems as well. As far as I can tell, the code still uses udelay() before calibration if io_delay=udelay? Just so we're clear on that... Yes. This patch is explicitly about the alternate port and not about udelay. As discussed (and changelogged) the calibration is just one problem with PCI posting and possible SMP races the other ones. Ingo Molnar wanted it as a debugging thing already though. Once we start discussing udelay() again I believe we should go with the simple per CPU-Family loops_per_jiffy initialization to fix that first problem (and I guess I could hack that in now) but then the bigger problem remains and will need a fair amount of testing at least and mostly on machines that are by now gathering dust in a few basements... 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: provide a DMI based port 0x80 I/O delay override.
On 17-12-07 00:12, David P. Reed wrote:
Rene Herman wrote:
David: I've plugged in your DMI values in this. Could you perhaps test
this to confirm that it works for you?
Will test it by tomorrow morning.
Might as well test the new version then. Ingo Molnar requested a few changes
and this fixes a couple of problems as well.
Rene.
commit 5001121e449040aa9cc021f69bfb191662c13004
Author: Rene Herman <[EMAIL PROTECTED]>
Date: Sun Dec 16 13:36:39 2007 +0100
x86: provide a DMI based port 0x80 I/O delay override.
Certain (HP) laptops experience trouble from our port 0x80 I/O delay
writes. This patch provides for a DMI based switch to the "alternate
diagnostic port" 0xed (as used by some BIOSes as well) for these.
David P. Reed confirmed that port 0xed works for him and provides a
proper delay. The symptoms of _not_ working are a hanging machine,
with "hwclock" use being a direct trigger.
Earlier versions of this attempted to simply use udelay(2), with the
2 being a value tested to be a nicely conservative upper-bound with
help from many on the linux-kernel mailinglist but that approach has
two problems.
First, pre-loops_per_jiffy calibration (which is post PIT init while
some implementations of the PIT are actually one of the historically
problematic devices that need the delay) udelay() isn't particularly
well-defined. We could initialise loops_per_jiffy conservatively (and
based on CPU family so as to not unduly delay old machines) which
would sort of work, but...
Second, delaying isn't the only effect that a write to port 0x80 has.
It's also a PCI posting barrier which some devices may be explicitly
or implicitly relying on. Alan Cox did a survey and found evidence
that additionally some drivers may be racy on SMP without the bus
locking outb.
Switching to an inb() makes the timing too unpredictable and as such,
this DMI based switch should be the safest approach for now. Any more
invasive changes should get more rigid testing first. It's moreover
only very few machines with the problem and a DMI based hack seems
to fit that situation.
This also introduces a command-line parameter "io_delay" to override
the DMI based choice again:
io_delay=
where "standard" means using the standard port 0x80 and "alternate"
port 0xed.
At the request of Ingo Molnar this retains the udelay method as a
config (CONFIG_UDELAY_IO_DELAY) and command-line ("io_delay=udelay")
choice for testing purposes as well.
This does not change the io_delay() in the boot code which is using
the same port 0x80 I/O delay but those do not appear to be a problem
as David P. Reed reported the problem was already gone after using the
udelay version. He moreover reported that booting with "acpi=off" also
fixed things and seeing as how ACPI isn't touched until after this DMI
based I/O port switch I believe it's safe to leave the ones in the boot
code be.
The DMI strings from David's HP Pavilion dv9000z are in there already
and we need to get/verify the DMI info from other machines with the
problem, notably the HP Pavilion dv6000z.
This patch is partly based on earlier patches from Pavel Machek and
David P. Reed.
Signed-off-by: Rene Herman <[EMAIL PROTECTED]>
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 33121d6..9dce154 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -785,6 +785,14 @@ and is between 256 and 4096 characters. It is defined in
the file
for translation below 32 bit and if not available
then look in the higher range.
+ io_delay= [X86-32,X86-64] I/O delay method
+ standard
+ Standard port 0x80 delay
+ alternate
+ Alternate port 0xed delay
+ udelay
+ Simple two microsecond delay
+
io7=[HW] IO7 for Marvel based alpha systems
See comment before marvel_specify_io7 in
arch/alpha/kernel/core_marvel.c.
diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index 761ca7b..40aba67 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -112,4 +112,13 @@ config IOMMU_LEAK
Add a simple leak tracer to the IOMMU code. This is useful when you
are debugging a buggy device driver that leaks IOMMU mappings.
+config UDELAY_IO_DELAY
+ bool "Delay I/O through udelay instead of outb"
+ depends on DEBUG_KERNEL
+ help
+ Make inb_p/outb_p use udelay() based delays by d
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
On 16-12-07 22:43, H. Peter Anvin wrote: Again, 24 is "right out". 25 is a "maybe", IMO. Rene's fix could be an exception, since it is a DMI-keyed workaround for a specific machine and doesn't change behaviour in general. I've not much opinion on the schedule as I've not the problem but yes, it's intended as the low risk option. 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: provide a DMI based port 0x80 I/O delay override.
On 16-12-07 22:42, H. Peter Anvin wrote: It probably comes down to which version is bigger (you probably also want to try uninlining.) slow_down_io() sort of needs to stay inline due to the REALLY_SLOW_IO thing. That stuff could use a cleanup, but that would be a diferent patch. Thanks for the heads up (also saw the SMBIOS update to this) but those don't seem to be a problem in fact. David Reed has been running with the simple udelay(2) version of this and reported no more hangs. He moreover reported no trouble after booting with "acpi=off" meaning that things seem to be fine pre-acpi which the boot code (and this io_delay_init) is. So I believe we get to ignore those. Okay, so there is something inside ACPI which tickles this. Which brings further credibility that it's activating a debugging hack, probably inside the SuperIO/system controller chip. It would be interesting to know exactly which part of ACPI triggers this. I bet it is a reference to system controller namespace. Do you expect a BIOS update to be able to fix it? If so, I guess any DMI hack should take BIOS version into account. 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: provide a DMI based port 0x80 I/O delay override.
On 16-12-07 16:22, Ingo Molnar wrote:
looks good to me. Could you please also provide three more controls that
i suggested earlier:
- a boot option enabling/disabling the udelay based code
- a .config method of enabling/disabling the udelay based code
- a sysctl to toggle it
if we want to clean this all up we'll need as many controls as possible.
This version does the boot and the .config option but not the sysctl. It
makes for clumsy code and I don't believe it provides for much added value
as soon as you have the boot option. I am moreover not completely confident
about things such as paravirt liking the possibility of the native_io_delay
being changed out from under them at unpredictable times.
So how is this? Also fixes a few problems with the previous version.
Documentation/kernel-parameters.txt |8 ++
arch/x86/Kconfig.debug |9 +++
arch/x86/boot/compressed/misc_32.c |8 +-
arch/x86/boot/compressed/misc_64.c |8 +-
arch/x86/kernel/Makefile_32 |2
arch/x86/kernel/Makefile_64 |2
arch/x86/kernel/io_delay.c | 103
arch/x86/kernel/setup_32.c |2
arch/x86/kernel/setup_64.c |2
include/asm-x86/io_32.h |6 --
include/asm-x86/io_64.h | 27 +
11 files changed, 152 insertions(+), 25 deletions(-)
Rene.
commit 5001121e449040aa9cc021f69bfb191662c13004
Author: Rene Herman <[EMAIL PROTECTED]>
Date: Sun Dec 16 13:36:39 2007 +0100
x86: provide a DMI based port 0x80 I/O delay override.
Certain (HP) laptops experience trouble from our port 0x80 I/O delay
writes. This patch provides for a DMI based switch to the "alternate
diagnostic port" 0xed (as used by some BIOSes as well) for these.
David P. Reed confirmed that port 0xed works for him and provides a
proper delay. The symptoms of _not_ working are a hanging machine,
with "hwclock" use being a direct trigger.
Earlier versions of this attempted to simply use udelay(2), with the
2 being a value tested to be a nicely conservative upper-bound with
help from many on the linux-kernel mailinglist but that approach has
two problems.
First, pre-loops_per_jiffy calibration (which is post PIT init while
some implementations of the PIT are actually one of the historically
problematic devices that need the delay) udelay() isn't particularly
well-defined. We could initialise loops_per_jiffy conservatively (and
based on CPU family so as to not unduly delay old machines) which
would sort of work, but...
Second, delaying isn't the only effect that a write to port 0x80 has.
It's also a PCI posting barrier which some devices may be explicitly
or implicitly relying on. Alan Cox did a survey and found evidence
that additionally some drivers may be racy on SMP without the bus
locking outb.
Switching to an inb() makes the timing too unpredictable and as such,
this DMI based switch should be the safest approach for now. Any more
invasive changes should get more rigid testing first. It's moreover
only very few machines with the problem and a DMI based hack seems
to fit that situation.
This also introduces a command-line parameter "io_delay" to override
the DMI based choice again:
io_delay=
where "standard" means using the standard port 0x80 and "alternate"
port 0xed.
At the request of Ingo Molnar this retains the udelay method as a
config (CONFIG_UDELAY_IO_DELAY) and command-line ("io_delay=udelay")
choice for testing purposes as well.
This does not change the io_delay() in the boot code which is using
the same port 0x80 I/O delay but those do not appear to be a problem
as David P. Reed reported the problem was already gone after using the
udelay version. He moreover reported that booting with "acpi=off" also
fixed things and seeing as how ACPI isn't touched until after this DMI
based I/O port switch I believe it's safe to leave the ones in the boot
code be.
The DMI strings from David's HP Pavilion dv9000z are in there already
and we need to get/verify the DMI info from other machines with the
problem, notably the HP Pavilion dv6000z.
This patch is partly based on earlier patches from Pavel Machek and
David P. Reed.
Signed-off-by: Rene Herman <[EMAIL PROTECTED]>
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 33121d6..9dce154 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -785,6 +785,14 @@ and is between 256 and 4096 characters. It is defined in
the file
for translation below 32 bit and if
