heavy Disk I/O and system stops reacting for seconds

heavy Disk I/O and system stops reacting for seconds

[Marc-Christian Petersen]

Hi there,

I think someone else notices this too, but anyway, i write down my 
experiences.

I've tested 2.4.19rc[1|2|3], AC tree, AA tree, jam tree and mjc tree
All of them shows up the same behaviour. If i do some disk i/o, f.e.:

tar xzpf linux-2.4.18.tar.gz; rm -rf linux-2.4.18

the system stopps reacting while untar/ungzipping the file for more than 5 
seconds. Nothing but the mouse reacts. This does NOT occur with 2.4.18 and 
early 2.4.19-pre's ...

System is a Celeron 800MHz, 256 MB RAM, EIDE UDMA100 Intel BX440 running ext3 
filesystem.

If you need more informations tell me what and I provide them.
If this is already fixed by someone, please tell me :-)

Please CC, i am not subscribed!

-- 
Kind regards
        Marc-Christian Petersen

http://sourceforge.net/projects/wolk

PGP/GnuPG Key: 1024D/408B2D54947750EC
Fingerprint: 8602 69E0 A9C2 A509 8661 2B0B 408B 2D54 9477 50EC
Key available at www.keyserver.net. Encrypted e-mail preferred.

Re: heavy Disk I/O and system stops reacting for seconds

[Adrian Bunk]

On Sun, 21 Jul 2002, Marc-Christian Petersen wrote:

> Hi there,
>
> I think someone else notices this too, but anyway, i write down my
> experiences.
>
> I've tested 2.4.19rc[1|2|3], AC tree, AA tree, jam tree and mjc tree
> All of them shows up the same behaviour. If i do some disk i/o, f.e.:
>
> tar xzpf linux-2.4.18.tar.gz; rm -rf linux-2.4.18
>
> the system stopps reacting while untar/ungzipping the file for more than 5
> seconds. Nothing but the mouse reacts. This does NOT occur with 2.4.18 and
> early 2.4.19-pre's ...
>...

I've seen this the first time four months ago - at that time the problem
was only present in the -ac kernels (but now it's also present in the -pre
kernels). My report is at [1]. It seems to be a problem that affects only
the handling of keyboard events. Quoting from what I wrote at [1]:

<--  snip  -->

I tried to start Gimp from the fvwm menu after I typed a letter - and
Gimp has completed its startup before the letter arrived in the xterm.

<--  snip  -->


cu
Adrian

[1] http://marc.theaimsgroup.com/?l=linux-kernel&m=101705972802903&w=2

-- 

You only think this is a free country. Like the US the UK spends a lot of
time explaining its a free country because its a police state.
								Alan Cox

Re: heavy Disk I/O and system stops reacting for seconds

[Marc-Christian Petersen]

On Sunday 21 July 2002 16:17, Adrian Bunk wrote:

Hi Adrian,

> On Sun, 21 Jul 2002, Marc-Christian Petersen wrote:
> > Hi there,
> >
> > I think someone else notices this too, but anyway, i write down my
> > experiences.
> >
> > I've tested 2.4.19rc[1|2|3], AC tree, AA tree, jam tree and mjc tree
> > All of them shows up the same behaviour. If i do some disk i/o, f.e.:
> >
> > tar xzpf linux-2.4.18.tar.gz; rm -rf linux-2.4.18
> >
> > the system stopps reacting while untar/ungzipping the file for more than
> > 5 seconds. Nothing but the mouse reacts. This does NOT occur with 2.4.18
> > and early 2.4.19-pre's ...
> >...
>
> <--  snip  -->
>
> I tried to start Gimp from the fvwm menu after I typed a letter - and
> Gimp has completed its startup before the letter arrived in the xterm.
for my tests this does not appear. System does nothing for some seconds, no 
keyboard input, no startup of programs, just nothing. Seems like flushing 
somewhat to disk.

I think i have the causer. I've downgraded ext3fs code to 2.4.18 code and 
those behaviour is gone! I think ext3fs needs a big deep review before 2.4.19 
gets final.

-- 
Kind regards
        Marc-Christian Petersen

http://sourceforge.net/projects/wolk

PGP/GnuPG Key: 1024D/408B2D54947750EC
Fingerprint: 8602 69E0 A9C2 A509 8661 2B0B 408B 2D54 9477 50EC
Key available at www.keyserver.net. Encrypted e-mail preferred.

CPU detection broken in 2.5.27?

[Markus Pfeiffer]

Hi all,

I just noticed that my /proc/cpuinfo states wrong or incomplete 
information about my processor. My PIII-1000M Processor is reported as 
00/0B (Stepping?) and with only 32 KB of cache (which obviously is the 
L1d and L1i value). I think this happened during the split of the CPU 
detection code... I found nothing about that in archives or similar 
(i.e. on the list).
Perhaps someone who knows how to do it can look into that as i would 
need hours just to understand just what they are doing there and to read 
the specs of the CPUID instruction etc

Thanks in advance

Markus

Re: CPU detection broken in 2.5.27?

[Dave Jones]

On Sun, Jul 21, 2002 at 06:07:26PM +0200, Markus Pfeiffer wrote:

 > I just noticed that my /proc/cpuinfo states wrong or incomplete 
 > information about my processor. My PIII-1000M Processor is reported as 
 > 00/0B (Stepping?)

Yep, I told Patrick about this last week sometime. The problem is
that only later Intels (from P4 onwards iirc) have the
name string cpuid function. Without which we need a table to
do the family/model/stepping translation to name strings.

It's not that much work (and most of it already exists in the
kernels before the per-cpu split up).

        Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: CPU detection broken in 2.5.27?

[Patrick Mochel]

On Sun, 21 Jul 2002, Dave Jones wrote:

> On Sun, Jul 21, 2002 at 06:07:26PM +0200, Markus Pfeiffer wrote:
> 
>  > I just noticed that my /proc/cpuinfo states wrong or incomplete 
>  > information about my processor. My PIII-1000M Processor is reported as 
>  > 00/0B (Stepping?)
> 
> Yep, I told Patrick about this last week sometime. The problem is
> that only later Intels (from P4 onwards iirc) have the
> name string cpuid function. Without which we need a table to
> do the family/model/stepping translation to name strings.
> 
> It's not that much work (and most of it already exists in the
> kernels before the per-cpu split up).

Sorry about the delay in fixing this. The fix is really simple - just 
re-add the ID tables for PIIIs. I also added one for P4s, since mine 
wasn't getting automatically named. Though, I don't know what the code 
name for the model is, so it just shows up as "Pentium 4 (Unknown)"...

	-pat

===== arch/i386/kernel/cpu/intel.c 1.3 vs edited =====
--- 1.3/arch/i386/kernel/cpu/intel.c	Wed Jul 10 03:46:31 2002
+++ edited/arch/i386/kernel/cpu/intel.c	Tue Jul 23 12:04:48 2002
@@ -350,6 +350,24 @@
 			  [8] "Mobile Pentium MMX"
 		  }
 		},
+		{ X86_VENDOR_INTEL,     6,
+		  { 
+			  [0] "Pentium Pro A-step",
+			  [1] "Pentium Pro", 
+			  [3] "Pentium II (Klamath)", 
+			  [5] "Pentium II (Deschutes)", 
+			  [6] "Mobile Pentium II",
+			  [7] "Pentium III (Katmai)", 
+			  [8] "Pentium III (Coppermine)", 
+			  [10] "Pentium III (Cascades)",
+			  [11] "Pentium III (Tualatin)",
+		  }
+		},
+		{ X86_VENDOR_INTEL,     15,
+		  { 
+			  [1] "Pentium 4 (Unknown)",
+		  }
+		},
 	},
 	c_init:		init_intel,
 	c_identify:	generic_identify,

Re: CPU detection broken in 2.5.27?

[Dave Jones]

On Tue, Jul 23, 2002 at 12:14:08PM -0700, Patrick Mochel wrote:

There are some problems here.

 > +		{ X86_VENDOR_INTEL,     6,
 > +		  { 
 > +			  [0] "Pentium Pro A-step",
 > +			  [1] "Pentium Pro", 
 > +			  [3] "Pentium II (Klamath)", 

[4] is Deschutes according to the docs I used for x86info.

 > +			  [5] "Pentium II (Deschutes)", 

What [5] is is dependant upon cache size & stepping.

stepping 0:
    0KB - Celeron (Covington)
    256KB - Mobile Pentium II (Dixon)
stepping 1-3 Pentium II (Deschutes)

 > +			  [6] "Mobile Pentium II",

cache size 128KB - Celeron (Mendocino)
Stepping 0/5 - Celeron-A
Stepping A - Mobile PII

 > +			  [8] "Pentium III (Coppermine)", 

L2 Cachesize == 128 == Celeron (Else P3)


 > +			  [10] "Pentium III (Cascades)",

6a0 is another P2 Deschutes aparently, but this seems
odd, and I should double check this sometime.

 > +			  [11] "Pentium III (Tualatin)",

Could be a celeron too. Not sure of cache size.

 > +			  [1] "Pentium 4 (Unknown)",

Model 5 = (Foster)
Unsure of other codenames.

        Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: CPU detection broken in 2.5.27?

[Patrick Mochel]

On Tue, 23 Jul 2002, Dave Jones wrote:

> On Tue, Jul 23, 2002 at 12:14:08PM -0700, Patrick Mochel wrote:
> 
> There are some problems here.

Heh. They've always been there, then. I really did re-add the table from 
an older arch/i386/kernel/setup.c ;)

>  > +		{ X86_VENDOR_INTEL,     6,

> [4] is Deschutes according to the docs I used for x86info.

Ok, I added it. 

>  > +			  [5] "Pentium II (Deschutes)", 
> 
> What [5] is is dependant upon cache size & stepping.
> 
> stepping 0:
>     0KB - Celeron (Covington)
>     256KB - Mobile Pentium II (Dixon)
> stepping 1-3 Pentium II (Deschutes)

The Celeron detection happens in init_intel(). 

>  > +			  [6] "Mobile Pentium II",
> 
> cache size 128KB - Celeron (Mendocino)

Handled in init_intel().

> Stepping 0/5 - Celeron-A

Added to init_intel().

> Stepping A - Mobile PII

Um, leave as default? 

>  > +			  [8] "Pentium III (Coppermine)", 
> 
> L2 Cachesize == 128 == Celeron (Else P3)

Handled in init_intel().

>  > +			  [10] "Pentium III (Cascades)",
> 
> 6a0 is another P2 Deschutes aparently, but this seems
> odd, and I should double check this sometime.

Leaving unchanged.

>  > +			  [11] "Pentium III (Tualatin)",
> 
> Could be a celeron too. Not sure of cache size.

Ditto, for the sake of ignorance. 

>  > + [1] "Pentium 4 (Unknown)",
> 
> Model 5 = (Foster)

Added. Wait, isn't Foster the one with HT? The ones I have say that they 
support it, so wouldn't that be a Foster (as well as stepping 5)? 

Updated patch appended. This updated version hasn't been tested, as I
don't have any of those processors at my disposal...

	-pat

Re: CPU detection broken in 2.5.27?

[Dave Jones]

On Tue, Jul 23, 2002 at 01:26:38PM -0700, Patrick Mochel wrote:

 > Heh. They've always been there, then. I really did re-add the table from 
 > an older arch/i386/kernel/setup.c ;)
 > 
 > The Celeron detection happens in init_intel(). 

Ah, ok. Then all those cases should magically work..

 > Added. Wait, isn't Foster the one with HT?

AFAIK yes. Don't have one to test with, so can't say for sure.

 > The ones I have say that they 
 > support it, so wouldn't that be a Foster (as well as stepping 5)? 

Which stepping do you have ?
 
 > Updated patch appended. This updated version hasn't been tested, as I
 > don't have any of those processors at my disposal...

-ENOAPPENDAGE.

        Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: CPU detection broken in 2.5.27?

[Patrick Mochel]

> Which stepping do you have ?

2.

>  > Updated patch appended. This updated version hasn't been tested, as I
>  > don't have any of those processors at my disposal...
> 
> -ENOAPPENDAGE.

Sorry, it was in the invisible charset. 

	-pat

===== arch/i386/kernel/cpu/intel.c 1.3 vs edited =====
--- 1.3/arch/i386/kernel/cpu/intel.c	Wed Jul 10 03:46:31 2002
+++ edited/arch/i386/kernel/cpu/intel.c	Tue Jul 23 13:25:01 2002
@@ -232,15 +232,19 @@
 	if (c->x86 == 6) {
 		switch (c->x86_model) {
 		case 5:
-			if (l2 == 0)
-				p = "Celeron (Covington)";
-			if (l2 == 256)
-				p = "Mobile Pentium II (Dixon)";
+			if (c->x86_mask == 0) {
+				if (l2 == 0)
+					p = "Celeron (Covington)";
+				else if (l2 == 256)
+					p = "Mobile Pentium II (Dixon)";
+			}
 			break;
 			
 		case 6:
 			if (l2 == 128)
 				p = "Celeron (Mendocino)";
+			else if (c->x86_mask == 0 || c->x86_mask == 5)
+				p = "Celeron-A";
 			break;
 			
 		case 8:
@@ -348,6 +352,26 @@
 			  [4] "Pentium MMX",
 			  [7] "Mobile Pentium 75 - 200", 
 			  [8] "Mobile Pentium MMX"
+		  }
+		},
+		{ X86_VENDOR_INTEL,     6,
+		  { 
+			  [0] "Pentium Pro A-step",
+			  [1] "Pentium Pro", 
+			  [3] "Pentium II (Klamath)", 
+			  [4] "Pentium II (Deschutes)", 
+			  [5] "Pentium II (Deschutes)", 
+			  [6] "Mobile Pentium II",
+			  [7] "Pentium III (Katmai)", 
+			  [8] "Pentium III (Coppermine)", 
+			  [10] "Pentium III (Cascades)",
+			  [11] "Pentium III (Tualatin)",
+		  }
+		},
+		{ X86_VENDOR_INTEL,     15,
+		  {
+			  [1] "Pentium 4 (Foster)",
+			  [5] "Pentium 4 (Foster)",
 		  }
 		},
 	},

Re: CPU detection broken in 2.5.27?

[Dave Jones]

On Tue, Jul 23, 2002 at 01:34:37PM -0700, Patrick Mochel wrote:
 > 
 > > Which stepping do you have ?
 > 2.

I meant ->x86_model there, I assume you did too, and you have a 0xF24/0xF27 cpu.
I wasn't aware these were HT aware. In fact, only 0xF50 are confirmed.
Interesting.

 > Sorry, it was in the invisible charset. 

Ah ok. I'll install the correct font later.

 > ===== arch/i386/kernel/cpu/intel.c 1.3 vs edited =====
 > --- 1.3/arch/i386/kernel/cpu/intel.c	Wed Jul 10 03:46:31 2002
 > +++ edited/arch/i386/kernel/cpu/intel.c	Tue Jul 23 13:25:01 2002
 > @@ -232,15 +232,19 @@
 >  	if (c->x86 == 6) {
 >  		switch (c->x86_model) {
 >  		case 5:
 > -			if (l2 == 0)
 > -				p = "Celeron (Covington)";
 > -			if (l2 == 256)
 > -				p = "Mobile Pentium II (Dixon)";
 > +			if (c->x86_mask == 0) {
 > +				if (l2 == 0)
 > +					p = "Celeron (Covington)";
 > +				else if (l2 == 256)
 > +					p = "Mobile Pentium II (Dixon)";

Something that just nagged me about this code.
Where are those strings stored ? If they're in the same
text as this code, we shouldn't be creating references to them,
as after boot, all this will go poof. (it's __init)

If they are stored there, a simple strdup/memcpy will fix it
of course, but I'm wondering if we even need to. Or does
our linker magic put strings in data sections ?

        Dave
 
-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: CPU detection broken in 2.5.27?

[Patrick Mochel]

On Tue, 23 Jul 2002, Dave Jones wrote:

> On Tue, Jul 23, 2002 at 01:34:37PM -0700, Patrick Mochel wrote:
>  > 
>  > > Which stepping do you have ?
>  > 2.
> 
> I meant ->x86_model there, I assume you did too, and you have a 0xF24/0xF27 cpu.
> I wasn't aware these were HT aware. In fact, only 0xF50 are confirmed.
> Interesting.

Actually, it's Family 15, Model 1, Stepping 2. Though the HT capability
shows up, it's disabled, so it's one of the pre-Foster P4s (though I don't
know what they're called).

>  > Sorry, it was in the invisible charset. 
> 
> Ah ok. I'll install the correct font later.

You should already have it, though you might have to look a bit harder. 

>  > ===== arch/i386/kernel/cpu/intel.c 1.3 vs edited =====
>  > --- 1.3/arch/i386/kernel/cpu/intel.c	Wed Jul 10 03:46:31 2002
>  > +++ edited/arch/i386/kernel/cpu/intel.c	Tue Jul 23 13:25:01 2002
>  > @@ -232,15 +232,19 @@
>  >  	if (c->x86 == 6) {
>  >  		switch (c->x86_model) {
>  >  		case 5:
>  > -			if (l2 == 0)
>  > -				p = "Celeron (Covington)";
>  > -			if (l2 == 256)
>  > -				p = "Mobile Pentium II (Dixon)";
>  > +			if (c->x86_mask == 0) {
>  > +				if (l2 == 0)
>  > +					p = "Celeron (Covington)";
>  > +				else if (l2 == 256)
>  > +					p = "Mobile Pentium II (Dixon)";
> 
> Something that just nagged me about this code.
> Where are those strings stored ? If they're in the same
> text as this code, we shouldn't be creating references to them,
> as after boot, all this will go poof. (it's __init)

They're being placed in .rodata, so they should be ok. 

New patch, with the name for my P4 reset..

	-pat

===== arch/i386/kernel/cpu/intel.c 1.3 vs edited =====
--- 1.3/arch/i386/kernel/cpu/intel.c	Wed Jul 10 03:46:31 2002
+++ edited/arch/i386/kernel/cpu/intel.c	Tue Jul 23 14:07:12 2002
@@ -232,15 +232,19 @@
 	if (c->x86 == 6) {
 		switch (c->x86_model) {
 		case 5:
-			if (l2 == 0)
-				p = "Celeron (Covington)";
-			if (l2 == 256)
-				p = "Mobile Pentium II (Dixon)";
+			if (c->x86_mask == 0) {
+				if (l2 == 0)
+					p = "Celeron (Covington)";
+				else if (l2 == 256)
+					p = "Mobile Pentium II (Dixon)";
+			}
 			break;
 			
 		case 6:
 			if (l2 == 128)
 				p = "Celeron (Mendocino)";
+			else if (c->x86_mask == 0 || c->x86_mask == 5)
+				p = "Celeron-A";
 			break;
 			
 		case 8:
@@ -348,6 +352,26 @@
 			  [4] "Pentium MMX",
 			  [7] "Mobile Pentium 75 - 200", 
 			  [8] "Mobile Pentium MMX"
+		  }
+		},
+		{ X86_VENDOR_INTEL,     6,
+		  { 
+			  [0] "Pentium Pro A-step",
+			  [1] "Pentium Pro", 
+			  [3] "Pentium II (Klamath)", 
+			  [4] "Pentium II (Deschutes)", 
+			  [5] "Pentium II (Deschutes)", 
+			  [6] "Mobile Pentium II",
+			  [7] "Pentium III (Katmai)", 
+			  [8] "Pentium III (Coppermine)", 
+			  [10] "Pentium III (Cascades)",
+			  [11] "Pentium III (Tualatin)",
+		  }
+		},
+		{ X86_VENDOR_INTEL,     15,
+		  {
+			  [1] "Pentium 4 (Unknown)",
+			  [5] "Pentium 4 (Foster)",
 		  }
 		},
 	},

Time problem with 2.5.27 on Intel (and kernel freezes...)

[Oliver Pitzeier]

Hi all!

Something seems to be wrong with my time... Is it the kernel, is
it my real time clock (I don't guess so...). Here is the
strange log... (Please have a look at the timestamps).

Jul 21 16:54:24 test kernel: Console: colour VGA+ 80x25
       ^^^^^^^^
Jul 21 16:53:58 test rc.sysinit: Mounting proc filesystem:  succeeded
       ^^^^^^^^
Jul 21 16:54:24 test random: Initializing random number generator:
succeeded
Jul 21 16:54:24 test kernel: Calibrating delay loop... 591.87 BogoMIPS
Jul 21 16:53:58 test rc.sysinit: Unmounting initrd:  succeeded
Jul 21 16:54:25 test kernel: Memory: 127524k/131060k available (1060k
kernel code, 3148k reserved, 299k data, 208k init, 0k highmem)
Jul 21 16:53:58 test sysctl: net.ipv4.ip_forward = 0
Jul 21 16:54:25 test kernel: Security Scaffold v1.0.0 initialized
Jul 21 16:53:58 test sysctl: net.ipv4.conf.default.rp_filter = 1
Jul 21 16:54:25 test kernel: Dentry-cache hash table entries: 16384
(order: 5, 131072 bytes)
Jul 21 16:53:58 test sysctl: kernel.core_uses_pid = 1
Jul 21 16:54:25 test kernel: Inode-cache hash table entries: 8192
(order: 4, 65536 bytes)
Jul 21 16:53:58 test rc.sysinit: Configuring kernel parameters:
succeeded
Jul 21 16:54:25 test kernel: Mount-cache hash table entries: 512 (order:
0, 4096 bytes)
Jul 21 16:53:58 test date: Sun Jul 21 16:53:51 CEST 2002
Jul 21 16:54:26 test netfs: Mounting other filesystems:  succeeded

!?

I also had the problem that my kernel seems to boot fine, but near the
end of initlevel
3 the kernel hangs. No panic, no log, it's just frozen.

Greetz,
 Oliver

Re: CPU detection broken in 2.5.27?

[Mikael Pettersson]

On Tue, 23 Jul 2002 14:08:52 -0700 (PDT), Patrick Mochel wrote:
>> I meant ->x86_model there, I assume you did too, and you have a 0xF24/0xF27 cpu.
>> I wasn't aware these were HT aware. In fact, only 0xF50 are confirmed.
>> Interesting.
>
>Actually, it's Family 15, Model 1, Stepping 2. Though the HT capability
>shows up, it's disabled, so it's one of the pre-Foster P4s (though I don't
>know what they're called).

cpuid 0xF12 is a standard Willamette core P4; I have one heating my room :-)
Model 2 should be Northwood, AFAIK.

But why the table? Aren't you using the extended cpuid levels and/or the
BrandID to get the names for cpuid 0x680 (coppermine) and above cpus?

/Mikael