Strange OOM problem (swap empty)

[Disconnect]

Last night one of our testbed fileservers went OOM for unknown
reasons.  (The log is attached.)  Its a moderately complex setup - 2
dual-core Opteron chips with 8G of (matched) ram under Xen.  The file
array (which was doing heavy writes from this node using rsync) is an
external multi-connected scsi using clvmd and ocfs2.  (The other node
had no problems, but it was not doing anything other than idling with
2 xen guests, also idle.)

Local filesystems and swap are on an internal scsi raid rather than
the shared device.

The confusing part is that the dump shows swap almost completely
unused. So shouldn't memory pressure have forced something out to
swap?

I can provide any other info that would be helpful (and I'm subscribed
to the list).

Jul 10 18:23:50 dvsc3 kernel: Free swap  = 5961616kB
Jul 10 18:23:50 dvsc3 kernel: Total swap = 6032368kB


OOM.log
Description: Binary data
host   : dvsc3
release: 2.6.18-4-xen-amd64
version: #1 SMP Fri May 4 02:40:51 UTC 2007
machine: x86_64
nr_cpus: 4
nr_nodes   : 1
sockets_per_node   : 2
cores_per_socket   : 2
threads_per_core   : 1
cpu_mhz: 2193
hw_caps: 
178bfbff:e3d3fbff::0010:0001::0003
total_memory   : 8191
free_memory: 6536
xen_major  : 3
xen_minor  : 0
xen_extra  : .3-1
xen_caps   : xen-3.0-x86_64
xen_pagesize   : 4096
platform_params: virt_start=0x8000
xen_changeset  : Tue Oct 17 22:09:52 2006 +0100 
cc_compiler: gcc version 4.1.2 20061028 (prerelease) (Debian 
4.1.1-19)
cc_compile_by  : ultrotter
cc_compile_domain  : debian.org
cc_compile_date: Fri Nov  3 00:21:27 CET 2006
xend_config_format : 2


cpuinfo
Description: Binary data


free
Description: Binary data
Name  ID Mem(MiB) VCPUs State   Time(s)
Domain-0   0  512 4 r- 24.7
dv-xeng3.internal  3  512 1 -b  2.2
dv-xeng5.internal  4  512 1 -b  2.1

Strange OOM problem (swap empty)

[Disconnect]

Last night one of our testbed fileservers went OOM for unknown
reasons.  (The log is attached.)  Its a moderately complex setup - 2
dual-core Opteron chips with 8G of (matched) ram under Xen.  The file
array (which was doing heavy writes from this node using rsync) is an
external multi-connected scsi using clvmd and ocfs2.  (The other node
had no problems, but it was not doing anything other than idling with
2 xen guests, also idle.)

Local filesystems and swap are on an internal scsi raid rather than
the shared device.

The confusing part is that the dump shows swap almost completely
unused. So shouldn't memory pressure have forced something out to
swap?

I can provide any other info that would be helpful (and I'm subscribed
to the list).

Jul 10 18:23:50 dvsc3 kernel: Free swap  = 5961616kB
Jul 10 18:23:50 dvsc3 kernel: Total swap = 6032368kB


OOM.log
Description: Binary data
host   : dvsc3
release: 2.6.18-4-xen-amd64
version: #1 SMP Fri May 4 02:40:51 UTC 2007
machine: x86_64
nr_cpus: 4
nr_nodes   : 1
sockets_per_node   : 2
cores_per_socket   : 2
threads_per_core   : 1
cpu_mhz: 2193
hw_caps: 
178bfbff:e3d3fbff::0010:0001::0003
total_memory   : 8191
free_memory: 6536
xen_major  : 3
xen_minor  : 0
xen_extra  : .3-1
xen_caps   : xen-3.0-x86_64
xen_pagesize   : 4096
platform_params: virt_start=0x8000
xen_changeset  : Tue Oct 17 22:09:52 2006 +0100 
cc_compiler: gcc version 4.1.2 20061028 (prerelease) (Debian 
4.1.1-19)
cc_compile_by  : ultrotter
cc_compile_domain  : debian.org
cc_compile_date: Fri Nov  3 00:21:27 CET 2006
xend_config_format : 2


cpuinfo
Description: Binary data


free
Description: Binary data
Name  ID Mem(MiB) VCPUs State   Time(s)
Domain-0   0  512 4 r- 24.7
dv-xeng3.internal  3  512 1 -b  2.2
dv-xeng5.internal  4  512 1 -b  2.1

Re: PROBLEM: system clock slow on Athlon AMD64 since 2.6.21

[Disconnect]

On 6/9/07, Mikael Pettersson <[EMAIL PROTECTED]> wrote:

According to your system description it seems that you have a
Targa Visionary laptop with a VIA chipset and a Mobile Athlon64.
If so, then you probably have the same problem I reported some time
ago: see 
and the followup messages. The conclusion was that the chipset's
ACPI PM timer slows down when the CPU is in C2.

The workaround is to boot with processor.max_cstate=1.



I was seeing the same problem on a Ferrari 3200 (with ubuntu kernels)
but more recent kernels (2.6.21.3-ck2-swsusp2) don't ever seem to
enter C2 at all - according to powertop (1.5) its always in C0. (And
yes, this solved the clock problem at the cost of power use.)

I can provide any additional details that might help, and I'm in a
decent position to test things right now.

processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 15
model   : 12
model name  : Mobile AMD Athlon 64 Processor 2800+
stepping: 0
cpu MHz : 800.000
cache size  : 512 KB
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm
3dnowext 3dnow
bogomips: 1605.13
TLB size: 1024 4K pages
clflush size: 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PROBLEM: system clock slow on Athlon AMD64 since 2.6.21

[Disconnect]

On 6/9/07, Mikael Pettersson [EMAIL PROTECTED] wrote:

According to your system description it seems that you have a
Targa Visionary laptop with a VIA chipset and a Mobile Athlon64.
If so, then you probably have the same problem I reported some time
ago: see http://marc.info/?l=linux-kernelm=117681226421346w=2
and the followup messages. The conclusion was that the chipset's
ACPI PM timer slows down when the CPU is in C2.

The workaround is to boot with processor.max_cstate=1.



I was seeing the same problem on a Ferrari 3200 (with ubuntu kernels)
but more recent kernels (2.6.21.3-ck2-swsusp2) don't ever seem to
enter C2 at all - according to powertop (1.5) its always in C0. (And
yes, this solved the clock problem at the cost of power use.)

I can provide any additional details that might help, and I'm in a
decent position to test things right now.

processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 15
model   : 12
model name  : Mobile AMD Athlon 64 Processor 2800+
stepping: 0
cpu MHz : 800.000
cache size  : 512 KB
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm
3dnowext 3dnow
bogomips: 1605.13
TLB size: 1024 4K pages
clflush size: 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Back to the future.

[Disconnect]

We used it (with great success) to replace bad UPSs on single-PSU
database servers under (light) load. No need for scheduled downtime,
etc.

The whole point of hibernation (or suspend to disk, or whatever you
call it) is that the system goes to a zero-power state and then can be
brought back to its original state. Closing in-progress network
connections has nothing to do with pausing a machine any more than
setting IM clients to 'away' would, or locking an X session. That sort
of side-effect needs to be handled outside the core of "put state out
to disk and read it back".

On 5/7/07, Pavel Machek <[EMAIL PROTECTED]> wrote:

Hi!

> I don't dispute that it sometimes works today.
>
> what I dispute is that makeing it work should be a contraint on a cleaner
> design that happens to cause tcp connections to fail on suspend-to-disk
> (hibernate).
>
> if you are dong suspend-to-disk for such a short period that TCP
> connections are able to recover (typically <15 min for most firewalls, in
> some cases <2 min for connections with keep-alive) is it really
> worth it?

People were using swsusp to move server from one room to another.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Back to the future.

[Disconnect]

We used it (with great success) to replace bad UPSs on single-PSU
database servers under (light) load. No need for scheduled downtime,
etc.

The whole point of hibernation (or suspend to disk, or whatever you
call it) is that the system goes to a zero-power state and then can be
brought back to its original state. Closing in-progress network
connections has nothing to do with pausing a machine any more than
setting IM clients to 'away' would, or locking an X session. That sort
of side-effect needs to be handled outside the core of put state out
to disk and read it back.

On 5/7/07, Pavel Machek [EMAIL PROTECTED] wrote:

Hi!

 I don't dispute that it sometimes works today.

 what I dispute is that makeing it work should be a contraint on a cleaner
 design that happens to cause tcp connections to fail on suspend-to-disk
 (hibernate).

 if you are dong suspend-to-disk for such a short period that TCP
 connections are able to recover (typically 15 min for most firewalls, in
 some cases 2 min for connections with keep-alive) is it really
 worth it?

People were using swsusp to move server from one room to another.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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.4.6-ac5 and VIA Athlon chipsets

[Disconnect]

Will this fix (or get closer to fixing) the K7-optimization crashes? (I'm
still hoping its something that isn't getting initialized correctly,
rather than just a bug.  BurnK7/BurnMMX work fine, memtest86 and the MMX
memtest work, windows seems to be using the full memory bandwidth, etc.)

On Thu, 19 Jul 2001, Alan Cox did have cause to say:

> Excellent. I hope soon to push the official via fix to Linus. The other good
> news is that I now have some official VIA contacts, so where there is a real 
> need information should flow to the right places.

---
-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C$ ULBS*$ P- L+++>+ 
E--- W+++ N+@ o+>$ K? w--->+ O- M V-- PS+() PE Y+@ PGP++() t
5--- X-- R tv+@ b>$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.4.6-ac5 and VIA Athlon chipsets

[Disconnect]

Will this fix (or get closer to fixing) the K7-optimization crashes? (I'm
still hoping its something that isn't getting initialized correctly,
rather than just a bug.  BurnK7/BurnMMX work fine, memtest86 and the MMX
memtest work, windows seems to be using the full memory bandwidth, etc.)

On Thu, 19 Jul 2001, Alan Cox did have cause to say:

 Excellent. I hope soon to push the official via fix to Linus. The other good
 news is that I now have some official VIA contacts, so where there is a real 
 need information should flow to the right places.

---
-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a--? C$ ULBS*$ P- L 
E--- W+++ N+@ o+$ K? w---+ O- M V-- PS+() PE Y+@ PGP++() t
5--- X-- R tv+@ b$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Controversy over dynamic linking -- how to end the panic

[Disconnect]

In-Reply-To: <[EMAIL PROTECTED]>

On Thu, 21 Jun 2001, Alan Cox did have cause to say:

> An application is clearly not a derivative work in the general case, and they
> are linked with glibc which is LGPL and gives the users the choice and right
> to run non-free apps. 

IANAL, and this may be a dumb question, but what about LGPLing the driver
abstraction layer and/or headers? (Presuming of course there -is- a driver
abstraction layer that would work for 99% of the drivers.)  That leaves
the kernel safe (since LGPL says link whatever under whichever license,
GPL is valid for kernel core) and -specifically- allows any license you
like for HW/SW vendors who want to make modules.

---
-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C$ ULBS*$ P- L+++>+ 
E--- W+++ N+@ o+>$ K? w--->+ O- M V-- PS+() PE Y+@ PGP++() t
5--- X-- R tv+@ b>$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Controversy over dynamic linking -- how to end the panic

[Disconnect]

In-Reply-To: [EMAIL PROTECTED]

On Thu, 21 Jun 2001, Alan Cox did have cause to say:

 An application is clearly not a derivative work in the general case, and they
 are linked with glibc which is LGPL and gives the users the choice and right
 to run non-free apps. 

IANAL, and this may be a dumb question, but what about LGPLing the driver
abstraction layer and/or headers? (Presuming of course there -is- a driver
abstraction layer that would work for 99% of the drivers.)  That leaves
the kernel safe (since LGPL says link whatever under whichever license,
GPL is valid for kernel core) and -specifically- allows any license you
like for HW/SW vendors who want to make modules.

---
-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a--? C$ ULBS*$ P- L 
E--- W+++ N+@ o+$ K? w---+ O- M V-- PS+() PE Y+@ PGP++() t
5--- X-- R tv+@ b$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: rsync hangs on RedHat 2.4.2 or stock 2.4.4

[Disconnect]

On Tue, 12 Jun 2001, David S. Miller did have cause to say:

> Look everyone, it was determined to be a deadlock because of some
> interaction between how rsync sets up it's communication channels
> with the ssh subprocess, readas: userland bug.

we're not using ssh. :(

---
-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C$ ULBS*$ P- L+++>+ 
E--- W+++ N+@ o+>$ K? w--->+ O- M V-- PS+() PE Y+@ PGP++() t
5--- X-- R tv+@ b>$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: rsync hangs on RedHat 2.4.2 or stock 2.4.4

[Disconnect]

On Tue, 12 Jun 2001, Rasmus Andersen did have cause to say:

> On Tue, Jun 12, 2001 at 02:59:12PM +0100, Jeremy Sanders wrote:
> > I'm getting numerous rsync (v2.4.6) problems under Linux 2.4.2 (RedHat
> > 7.1) or stock 2.4.4 on several machines. rsync often hangs copying files
> 
> I could swear that during early 240-testX this was not a problem,
> but when I finally made a report about it and tried to go back
> through earlier kernels, I could not reproduce. Also, this is
> not reproducable under 2.2.X (for me, at least).

Just a 'me too!' but I'm inclined to think 'rsync bug' because it happens
on Redhat+2.4.x, Debian+2.4.x and Debian+2.2.18 - we finally gave up on
rsync for big-stuff-site-to-site and went back to scp. (It was -way-
faster to scp 4 gigs than to rsync the 50 megs or so of changes. It would
run, then freeze (usually at different places - if it froze twice in the
same place we'd just scp the file manually), so we'd wander past and
kill/restart it, repeat. Fastest total was 4 days, where the two of us
checked it every couple of hours over the weekend.)

We're (trying to) using it in real-life-big-data environment, so if you
need debuggers/more info/etc let me know. 

(I'm on LKML but not rsync-bugs, so cc me from that side.. thanks!)

---
-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C$ ULBS*$ P- L+++>+ 
E--- W+++ N+@ o+>$ K? w--->+ O- M V-- PS+() PE Y+@ PGP++() t
5--- X-- R tv+@ b>$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: rsync hangs on RedHat 2.4.2 or stock 2.4.4

[Disconnect]

On Tue, 12 Jun 2001, Rasmus Andersen did have cause to say:

 On Tue, Jun 12, 2001 at 02:59:12PM +0100, Jeremy Sanders wrote:
  I'm getting numerous rsync (v2.4.6) problems under Linux 2.4.2 (RedHat
  7.1) or stock 2.4.4 on several machines. rsync often hangs copying files
 
 I could swear that during early 240-testX this was not a problem,
 but when I finally made a report about it and tried to go back
 through earlier kernels, I could not reproduce. Also, this is
 not reproducable under 2.2.X (for me, at least).

Just a 'me too!' but I'm inclined to think 'rsync bug' because it happens
on Redhat+2.4.x, Debian+2.4.x and Debian+2.2.18 - we finally gave up on
rsync for big-stuff-site-to-site and went back to scp. (It was -way-
faster to scp 4 gigs than to rsync the 50 megs or so of changes. It would
run, then freeze (usually at different places - if it froze twice in the
same place we'd just scp the file manually), so we'd wander past and
kill/restart it, repeat. Fastest total was 4 days, where the two of us
checked it every couple of hours over the weekend.)

We're (trying to) using it in real-life-big-data environment, so if you
need debuggers/more info/etc let me know. 

(I'm on LKML but not rsync-bugs, so cc me from that side.. thanks!)

---
-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a--? C$ ULBS*$ P- L 
E--- W+++ N+@ o+$ K? w---+ O- M V-- PS+() PE Y+@ PGP++() t
5--- X-- R tv+@ b$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: rsync hangs on RedHat 2.4.2 or stock 2.4.4

[Disconnect]

On Tue, 12 Jun 2001, David S. Miller did have cause to say:

 Look everyone, it was determined to be a deadlock because of some
 interaction between how rsync sets up it's communication channels
 with the ssh subprocess, readas: userland bug.

we're not using ssh. :(

---
-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a--? C$ ULBS*$ P- L 
E--- W+++ N+@ o+$ K? w---+ O- M V-- PS+() PE Y+@ PGP++() t
5--- X-- R tv+@ b$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Break 2.4 VM in five easy steps

[Disconnect]

On Tue, 05 Jun 2001, Derek Glidden did have cause to say:

> > The swapoff algorithms in 2.2 and 2.4 are basically identical.
> > The problem *appears* worse in 2.4 because it uses lots
> > more swap.
> 
> I disagree with the terminology you're using.  It *is* worse in 2.4,
> period.  If it only *appears* worse, then if I encounter a situation
> where a 2.2 box has utilized as much swap as a 2.4 box, I should see the
> same results.  Yet this happens not to be the case. 

Ditto here - my box (1.2g tbird, 512M ram, 128M+128M swap, mixed scsi/ide)
does the same on swapoff -- 2.2.16 can be 100 megs or more into swap, and
it gets sluggish for a bit and then is fine.  2.4.[123] can be only 10
megs into swap and it basically hardlocks for about 5-10 minutes.

---

-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C$ ULBS*$ P- L+++>+ 
E--- W+++ N+@ o+>$ K? w--->+ O- M V-- PS+() PE Y+@ PGP++() t
5--- X-- R tv+@ b>$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Break 2.4 VM in five easy steps

[Disconnect]

On Tue, 05 Jun 2001, Derek Glidden did have cause to say:

  The swapoff algorithms in 2.2 and 2.4 are basically identical.
  The problem *appears* worse in 2.4 because it uses lots
  more swap.
 
 I disagree with the terminology you're using.  It *is* worse in 2.4,
 period.  If it only *appears* worse, then if I encounter a situation
 where a 2.2 box has utilized as much swap as a 2.4 box, I should see the
 same results.  Yet this happens not to be the case. 

Ditto here - my box (1.2g tbird, 512M ram, 128M+128M swap, mixed scsi/ide)
does the same on swapoff -- 2.2.16 can be 100 megs or more into swap, and
it gets sluggish for a bit and then is fine.  2.4.[123] can be only 10
megs into swap and it basically hardlocks for about 5-10 minutes.

---

-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a--? C$ ULBS*$ P- L 
E--- W+++ N+@ o+$ K? w---+ O- M V-- PS+() PE Y+@ PGP++() t
5--- X-- R tv+@ b$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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] fbdev logo (fwd)

[Disconnect]

Ditto - I'd like at least an option of the "incorrect" logo.  I can
(sorta) see not having it as the default.  But perhaps under the
'experimental drivers' tag, have an option of "Politically incorrect
framebuffer logo".  (If there isn't a huge outcry against it, I may work
up a patch - been meaning to get into kernel stuff, and this seems
relatively harmless.)

On Fri, 25 May 2001, Dr. Kelsey Hudson did have cause to say:

> On Thu, 10 May 2001, Geert Uytterhoeven wrote:
> >   - Political fixes:
> >   o There were still some penguins left carrying a glass of beer or wine.
> > This problem is about 2 years old!
> 
> I still don't understand why the penguin holding beer/wine was wrong...
> 
>  Kelsey Hudson   [EMAIL PROTECTED]
>  Software Engineer
>  Compendium Technologies, Inc   (619) 725-0771
> ---
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
---
   _.-==-._
| [EMAIL PROTECTED]| And Remember...
\  [EMAIL PROTECTED]  / He who controls Purple controls the Universe..
 PGP Key given on Request  Or at least the Purple parts!

-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C$ ULBS*$ P- L+++>+ 
E--- W+++ N+@ o+>$ K? w--->+ O- M V-- PS+() PE Y+@ PGP++() t
5--- X-- R tv+@ b>$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] fbdev logo (fwd)

[Disconnect]

Ditto - I'd like at least an option of the incorrect logo.  I can
(sorta) see not having it as the default.  But perhaps under the
'experimental drivers' tag, have an option of Politically incorrect
framebuffer logo.  (If there isn't a huge outcry against it, I may work
up a patch - been meaning to get into kernel stuff, and this seems
relatively harmless.)

On Fri, 25 May 2001, Dr. Kelsey Hudson did have cause to say:

 On Thu, 10 May 2001, Geert Uytterhoeven wrote:
- Political fixes:
o There were still some penguins left carrying a glass of beer or wine.
  This problem is about 2 years old!
 
 I still don't understand why the penguin holding beer/wine was wrong...
 
  Kelsey Hudson   [EMAIL PROTECTED]
  Software Engineer
  Compendium Technologies, Inc   (619) 725-0771
 ---
 
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
---
   _.-=Disconnect=-._
| [EMAIL PROTECTED]| And Remember...
\  [EMAIL PROTECTED]  / He who controls Purple controls the Universe..
 PGP Key given on Request  Or at least the Purple parts!

-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a--? C$ ULBS*$ P- L 
E--- W+++ N+@ o+$ K? w---+ O- M V-- PS+() PE Y+@ PGP++() t
5--- X-- R tv+@ b$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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] Single user linux

[Disconnect]

On Wed, 25 Apr 2001, Ronald Bultje did have cause to say:

> Who says it needs to compile? Who says it needs software installed? Who
> says it needs to run the software itself?

My current project (and I'm just waiting for nfs and wvlan_cs to stabalize
on ARM before putting the final touches on it) is an ipaq nfsrooted to a
Debian image, over the wireless lan.  Works like a champ, and it -does-
compile stuff reasonably fast (well, reasonably fast considering the data
is all on the far side of 11M/sec wireless.)  My kit is mostly portable as
well, since the nfs server is on the libretto and runs just fine in my
backpack ;)

The next step is bludgeoning debian-arm into not running 50-100 little
servers I don't need on my PIM.  But that may be the function of a
task-nfs-ipaq package or some such.

So far -multiuser- linux on PIMs ("true" linux, with X, etc, as distinct
from pocketlinux/qpe/etc, which are a different animal in this case) is
almost there.  Web browsers are coming along nicely (and remote-X netscape
is usable, although barely) and there are several nice imap clients. (and
input methods ranging from a handwriting system to a little onscreen
keyboard, if you are in a situation where an external keyboard is not
feasable.)

---
-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C$ ULBS*$ P- L+++>+ 
E--- W+++ N+@ o+>$ K? w--->+ O- M V-- PS+() PE Y+@ PGP++() t
5--- X-- R tv+@ b>$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Single user linux

[Disconnect]

On Wed, 25 Apr 2001, Ronald Bultje did have cause to say:

 Who says it needs to compile? Who says it needs software installed? Who
 says it needs to run the software itself?

My current project (and I'm just waiting for nfs and wvlan_cs to stabalize
on ARM before putting the final touches on it) is an ipaq nfsrooted to a
Debian image, over the wireless lan.  Works like a champ, and it -does-
compile stuff reasonably fast (well, reasonably fast considering the data
is all on the far side of 11M/sec wireless.)  My kit is mostly portable as
well, since the nfs server is on the libretto and runs just fine in my
backpack ;)

The next step is bludgeoning debian-arm into not running 50-100 little
servers I don't need on my PIM.  But that may be the function of a
task-nfs-ipaq package or some such.

So far -multiuser- linux on PIMs (true linux, with X, etc, as distinct
from pocketlinux/qpe/etc, which are a different animal in this case) is
almost there.  Web browsers are coming along nicely (and remote-X netscape
is usable, although barely) and there are several nice imap clients. (and
input methods ranging from a handwriting system to a little onscreen
keyboard, if you are in a situation where an external keyboard is not
feasable.)

---
-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a--? C$ ULBS*$ P- L 
E--- W+++ N+@ o+$ K? w---+ O- M V-- PS+() PE Y+@ PGP++() t
5--- X-- R tv+@ b$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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] Single user linux

[Disconnect]

On Tue, 24 Apr 2001, Aaron Lehmann did have cause to say:

> On Wed, Apr 25, 2001 at 10:07:48AM +1000, Daniel Stone wrote:
> > What real value does it have, apart from the geek "look at me, I'm using
> > bash" value?
> 
> I don't really want to get into it at the moment, but imagine hacking
> netfilter without lugging a laptop around. PDA's are sleek and cool,
> and using UNIX on them lets you write shell scripts to sort your
> addresses and stuff like that. Basically it's everything that's cool
> about Unix as a workstation OS scaled down to PDA-size.

Two (not quite exclusive ;) ..) points:

First, most pda's have apps like telnet/ssh/etc available. (And even more
specific apps are available for various uses - I recall a palm pilot app
that talked to cisco gear and gave a nice gui for 90% of the config, plus
a terminal for the rest.)

And second, I agree that there are some great advantages to small linux
(my ipaq runs linux, and my barely larger libretto is a full debian
mirror) but all of these (even pocketlinux, which is basically not linux)
work with the concept of multiple users.  Whether for profiles or for
system vs user, they all use it.  This patch is trash.



-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C$ ULBS*$ P- L+++>+ 
E--- W+++ N+@ o+>$ K? w--->+ O- M V-- PS+() PE Y+@ PGP++() t
5--- X-- R tv+@ b>$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Single user linux

[Disconnect]

On Tue, 24 Apr 2001, Aaron Lehmann did have cause to say:

 On Wed, Apr 25, 2001 at 10:07:48AM +1000, Daniel Stone wrote:
  What real value does it have, apart from the geek look at me, I'm using
  bash value?
 
 I don't really want to get into it at the moment, but imagine hacking
 netfilter without lugging a laptop around. PDA's are sleek and cool,
 and using UNIX on them lets you write shell scripts to sort your
 addresses and stuff like that. Basically it's everything that's cool
 about Unix as a workstation OS scaled down to PDA-size.

Two (not quite exclusive ;) ..) points:

First, most pda's have apps like telnet/ssh/etc available. (And even more
specific apps are available for various uses - I recall a palm pilot app
that talked to cisco gear and gave a nice gui for 90% of the config, plus
a terminal for the rest.)

And second, I agree that there are some great advantages to small linux
(my ipaq runs linux, and my barely larger libretto is a full debian
mirror) but all of these (even pocketlinux, which is basically not linux)
work with the concept of multiple users.  Whether for profiles or for
system vs user, they all use it.  This patch is trash.



-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a--? C$ ULBS*$ P- L 
E--- W+++ N+@ o+$ K? w---+ O- M V-- PS+() PE Y+@ PGP++() t
5--- X-- R tv+@ b$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Athlon problem report summary

[Disconnect]

> I wrote a set of programs to tune the MMX code. Arjan I suspect did similar
> when he reoptimised the code for the newer Athlon. Simple stuff like

Alan - your proggy ran (no output) for about 5 seconds or so, then exited.

Arjan - from yours, I get the results below.  Either way, no OOPs, no
errors, etc.  (Felt pretty silly as I remounted all my drives and brought
it back up to multi-user mode ;) ..)

So am I correct in assuming at this point that MMX is working fine on this
mobo/chip combo?  What's next?


Athlon test program $Id: fast.c,v 1.6 2000/09/23 09:05:45 arjan Exp $
clear_page() tests
clear_page function 'warm up run'took 16151 cycles per page
clear_page function '2.4 non MMX'took 11893 cycles per page
clear_page function '2.4 MMX fallback'   took 11736 cycles per page
clear_page function '2.4 MMX version'took 10436 cycles per page
clear_page function 'faster_clear_page'  took 4998 cycles per page
clear_page function 'even_faster_clear'  took 4881 cycles per page

copy_page() tests
copy_page function 'warm up run' took 17595 cycles per page
copy_page function '2.4 non MMX' took 26701 cycles per page
copy_page function '2.4 MMX fallback'took 26708 cycles per page
copy_page function '2.4 MMX version' took 17649 cycles per page
copy_page function 'faster_copy' took 10480 cycles per page
copy_page function 'even_faster' took 10464 cycles per page


-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C$ ULBS*$ P+>+++ L>+ 
E--- W+++ N+@ o+>$ K? w--->+ O- M V-- PS+() PE Y+@ PGP++() t 5--- 
X-- R tv+@ b>$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Athlon problem report summary

[Disconnect]

 I wrote a set of programs to tune the MMX code. Arjan I suspect did similar
 when he reoptimised the code for the newer Athlon. Simple stuff like

Alan - your proggy ran (no output) for about 5 seconds or so, then exited.

Arjan - from yours, I get the results below.  Either way, no OOPs, no
errors, etc.  (Felt pretty silly as I remounted all my drives and brought
it back up to multi-user mode ;) ..)

So am I correct in assuming at this point that MMX is working fine on this
mobo/chip combo?  What's next?


Athlon test program $Id: fast.c,v 1.6 2000/09/23 09:05:45 arjan Exp $
clear_page() tests
clear_page function 'warm up run'took 16151 cycles per page
clear_page function '2.4 non MMX'took 11893 cycles per page
clear_page function '2.4 MMX fallback'   took 11736 cycles per page
clear_page function '2.4 MMX version'took 10436 cycles per page
clear_page function 'faster_clear_page'  took 4998 cycles per page
clear_page function 'even_faster_clear'  took 4881 cycles per page

copy_page() tests
copy_page function 'warm up run' took 17595 cycles per page
copy_page function '2.4 non MMX' took 26701 cycles per page
copy_page function '2.4 MMX fallback'took 26708 cycles per page
copy_page function '2.4 MMX version' took 17649 cycles per page
copy_page function 'faster_copy' took 10480 cycles per page
copy_page function 'even_faster' took 10464 cycles per page


-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a--? C$ ULBS*$ P L+ 
E--- W+++ N+@ o+$ K? w---+ O- M V-- PS+() PE Y+@ PGP++() t 5--- 
X-- R tv+@ b$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Athlon problem report summary

[Disconnect]

On Sat, 21 Apr 2001, Alan Cox did have cause to say:

> K7 optimisation basically enabled the MMX copy/clear code which adds 30-40%
> performance to those functions. It also materially ups the maximum memory
> bandwidth the processor will use which may be where the fun starts.

Not to be slow/dull/etc (I -really- appreciate the help here) but possibly
more stupid questions.

Is there anything out there to test/benchmark MMX ops? (Preferably with
reporting on MMX and equiv non-MMX ops, tunable memory bandwidth, etc.)

Also, I can try that same kernel w/ memory set to HCLK (pc100) instead of
HCLK+33 (pc133).  The ram is pc133, but who knows, it might work.  (I'm
pretty sure I had it at pc100 before with no change, but not positive.)

---
-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C$ ULBS*$ P+>+++ L>+ 
E--- W+++ N+@ o+>$ K? w--->+ O- M V-- PS+() PE Y+@ PGP++() t 5--- 
X-- R tv+@ b>$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Athlon problem report summary

[Disconnect]

On Sat, 21 Apr 2001, Alan Cox did have cause to say:

> > Addendum to 1. So far everyone (at least on LKML) who has had the
> > crash-immediatly-do-not-pass-go issues has been using an iwill kk266 (or
> > kk266r, IIRC) mobo.
> 
> Not quite all. Many have but I have other reports.

Oddness. Is it all on that same via chipset? (I have seen some reports of
the same chipset working on other mobos.)

> As far as I can tell its hardware problems. The fact not a single AMD chipset
> user sees it makes me very suspicious indeed.

Fair enough - I think so as well (although slightly less so since it's
not just the iwill mobo.)

On a (possibly?) unrelated note, memtest-mmx fails immediately (prints the
version, hardlocks).  But I've seen that on a stock PIII as well, so I
don't know what that's worth.  The oops I managed to decode was in
mmx_copy_page.

Is there a way to enable everything-K7-except-MMX? (Or, for that matter,
an easy way to see what K7 does that K6 doesn't.)

---
-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C$ ULBS*$ P+>+++ L>+ 
E--- W+++ N+@ o+>$ K? w--->+ O- M V-- PS+() PE Y+@ PGP++() t 5--- 
X-- R tv+@ b>$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Athlon problem report summary

[Disconnect]

Addendum to 1. So far everyone (at least on LKML) who has had the
crash-immediatly-do-not-pass-go issues has been using an iwill kk266 (or
kk266r, IIRC) mobo.

Have we gotten any fix, other than not using K7 optimizations?

I'm willing to keep trying new patches, if necessary.  (And for that
matter, the box is on dialup behind masq, but if you are interested I can
set up an account.  No serial console, no remote power cycle, so I'm not
sure how much good it'll do, but it's an option if you want/need it.)

On Mon, 16 Apr 2001, Alan Cox did have cause to say:

> There appear to be two common threads to this
> 
> 1.  'It runs if I don't use Athlon optimisations'
> 
> This one is compiler independant. It seems to be unrelated to obvious 
> candidates like vesafb. It isnt related to CPU version. Every victim has a 
> VIA chipset machine.
> 
> 
> 2.  'My athlon box is fine until I am swapping' {and using DMA}
> 
> Compiler independant, CPU version independant. All victims have a VIA chipset.
> This one may be linked to the reported problems with VIA PCI. Two of the 
> reporters found disabling IDE DMA fixed this one
> 
> 
> Nobody using an AMD chipset has reported either problem.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
---
   _.-==-._
| [EMAIL PROTECTED]| And Remember...
\  [EMAIL PROTECTED]  / He who controls Purple controls the Universe..
 PGP Key given on Request  Or at least the Purple parts!

-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C$ ULBS*$ P+>+++ L>+ 
E--- W+++ N+@ o+>$ K? w--->+ O- M V-- PS+() PE Y+@ PGP++() t 5--- 
X-- R tv+@ b>$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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: pageable kernel-segments

[Disconnect]

On Tue, 17 Apr 2001, Oliver Neukum did have cause to say:

> > load/init/etc.  Hardware setup tends to only happen once..)
> 
> No they can't. Modules can't be finegrained enough to do this without wasting 
> more memory due to fragmentation than you'd gain.

Actually, don't they do this -already-?  I thought I saw somewhere on here
recently that there was a class of functions you could use in a module for
'one-off' activities.  I suspect that covers 90% of what could be paged
out (the remainder being mostly the unloading process, for non-hotswap
modules).  But IANAKG. (..not a kernel guru).

> Actually not that great.Support for different types of kernel code is there 
> to support __init and __initdata. You'd use a fixup scheme like the one used 
> in copy_[to|from]_user to trigger paging in. Page out could be handled by the 
> conventional mm.

I mis-typed - by 'major rewrite' I meant more an analysis and tagging
process, which would have to touch most of the kernel before it was
useful. But again, IANAKG so the existing swap code may already handle
that, at least in a way that it could be a ruleset (with override tags?)
instead of having to put a new set of tags everywhere.

---
-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C$ ULBS*$ P+>+++ L>+ 
E--- W+++ N+@ o+>$ K? w--->+ O- M V-- PS+() PE Y+@ PGP++() t 5--- 
X-- R tv+@ b>$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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: pageable kernel-segments

[Disconnect]

On Tue, 17 Apr 2001, Oliver Neukum did have cause to say:

  load/init/etc.  Hardware setup tends to only happen once..)
 
 No they can't. Modules can't be finegrained enough to do this without wasting 
 more memory due to fragmentation than you'd gain.

Actually, don't they do this -already-?  I thought I saw somewhere on here
recently that there was a class of functions you could use in a module for
'one-off' activities.  I suspect that covers 90% of what could be paged
out (the remainder being mostly the unloading process, for non-hotswap
modules).  But IANAKG. (..not a kernel guru).

 Actually not that great.Support for different types of kernel code is there 
 to support __init and __initdata. You'd use a fixup scheme like the one used 
 in copy_[to|from]_user to trigger paging in. Page out could be handled by the 
 conventional mm.

I mis-typed - by 'major rewrite' I meant more an analysis and tagging
process, which would have to touch most of the kernel before it was
useful. But again, IANAKG so the existing swap code may already handle
that, at least in a way that it could be a ruleset (with override tags?)
instead of having to put a new set of tags everywhere.

---
-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a--? C$ ULBS*$ P L+ 
E--- W+++ N+@ o+$ K? w---+ O- M V-- PS+() PE Y+@ PGP++() t 5--- 
X-- R tv+@ b$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Athlon problem report summary

[Disconnect]

Addendum to 1. So far everyone (at least on LKML) who has had the
crash-immediatly-do-not-pass-go issues has been using an iwill kk266 (or
kk266r, IIRC) mobo.

Have we gotten any fix, other than not using K7 optimizations?

I'm willing to keep trying new patches, if necessary.  (And for that
matter, the box is on dialup behind masq, but if you are interested I can
set up an account.  No serial console, no remote power cycle, so I'm not
sure how much good it'll do, but it's an option if you want/need it.)

On Mon, 16 Apr 2001, Alan Cox did have cause to say:

 There appear to be two common threads to this
 
 1.  'It runs if I don't use Athlon optimisations'
 
 This one is compiler independant. It seems to be unrelated to obvious 
 candidates like vesafb. It isnt related to CPU version. Every victim has a 
 VIA chipset machine.
 
 
 2.  'My athlon box is fine until I am swapping' {and using DMA}
 
 Compiler independant, CPU version independant. All victims have a VIA chipset.
 This one may be linked to the reported problems with VIA PCI. Two of the 
 reporters found disabling IDE DMA fixed this one
 
 
 Nobody using an AMD chipset has reported either problem.
 
 -
 To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
---
   _.-=Disconnect=-._
| [EMAIL PROTECTED]| And Remember...
\  [EMAIL PROTECTED]  / He who controls Purple controls the Universe..
 PGP Key given on Request  Or at least the Purple parts!

-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a--? C$ ULBS*$ P L+ 
E--- W+++ N+@ o+$ K? w---+ O- M V-- PS+() PE Y+@ PGP++() t 5--- 
X-- R tv+@ b$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Athlon problem report summary

[Disconnect]

On Sat, 21 Apr 2001, Alan Cox did have cause to say:

  Addendum to 1. So far everyone (at least on LKML) who has had the
  crash-immediatly-do-not-pass-go issues has been using an iwill kk266 (or
  kk266r, IIRC) mobo.
 
 Not quite all. Many have but I have other reports.

Oddness. Is it all on that same via chipset? (I have seen some reports of
the same chipset working on other mobos.)

 As far as I can tell its hardware problems. The fact not a single AMD chipset
 user sees it makes me very suspicious indeed.

Fair enough - I think so as well (although slightly less so since it's
not just the iwill mobo.)

On a (possibly?) unrelated note, memtest-mmx fails immediately (prints the
version, hardlocks).  But I've seen that on a stock PIII as well, so I
don't know what that's worth.  The oops I managed to decode was in
mmx_copy_page.

Is there a way to enable everything-K7-except-MMX? (Or, for that matter,
an easy way to see what K7 does that K6 doesn't.)

---
-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a--? C$ ULBS*$ P L+ 
E--- W+++ N+@ o+$ K? w---+ O- M V-- PS+() PE Y+@ PGP++() t 5--- 
X-- R tv+@ b$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Athlon problem report summary

[Disconnect]

On Sat, 21 Apr 2001, Alan Cox did have cause to say:

 K7 optimisation basically enabled the MMX copy/clear code which adds 30-40%
 performance to those functions. It also materially ups the maximum memory
 bandwidth the processor will use which may be where the fun starts.

Not to be slow/dull/etc (I -really- appreciate the help here) but possibly
more stupid questions.

Is there anything out there to test/benchmark MMX ops? (Preferably with
reporting on MMX and equiv non-MMX ops, tunable memory bandwidth, etc.)

Also, I can try that same kernel w/ memory set to HCLK (pc100) instead of
HCLK+33 (pc133).  The ram is pc133, but who knows, it might work.  (I'm
pretty sure I had it at pc100 before with no change, but not positive.)

---
-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a--? C$ ULBS*$ P L+ 
E--- W+++ N+@ o+$ K? w---+ O- M V-- PS+() PE Y+@ PGP++() t 5--- 
X-- R tv+@ b$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Bug in serial.c

[Disconnect]

On Thu, 19 Apr 2001, Marc Karasek did have cause to say:

> 2) In 2.4.3 the console port using ttySX is broken.  It dumps fine to the
> terminal but when you get to a point of entering data (login, configuration
> scripts, etc) the terminal does not accept any input.  

Most gettys and such take a /dev/tty* argument, which has to be changed to
point to the serial port for a serial console. Config scripts (and
anything else) specifically using /dev/tty or /dev/console should work
fine, however. (I wouldn't recommend pointing a getty at /dev/console - we
had some issues on a headless server trying that. Easiest to point it at
/dev/ttyS0 or whatnot.)

> 
> So far I have been able to debug to the point where I see that the kernel is
> receiving the characters from the serial.c driver.  But it never echos them
> or does anything else with them.  I will continue to look into this at this
> end.  
> 
> I was also wondering if anyone else has seen this or if a patch is avail for
> this bug??
> 
> Marc Karasek
> Sr. Firmware Engineer
> iVivity Inc
> [EMAIL PROTECTED]  
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
---
   _.-==-._
| [EMAIL PROTECTED]| And Remember...
\  [EMAIL PROTECTED]  / He who controls Purple controls the Universe..
 PGP Key given on Request  Or at least the Purple parts!

-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C$ ULBS*$ P+>+++ L>+ 
E--- W+++ N+@ o+>$ K? w--->+ O- M V-- PS+() PE Y+@ PGP++() t 5--- 
X-- R tv+@ b>$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Bug in serial.c

[Disconnect]

On Thu, 19 Apr 2001, Marc Karasek did have cause to say:

 2) In 2.4.3 the console port using ttySX is broken.  It dumps fine to the
 terminal but when you get to a point of entering data (login, configuration
 scripts, etc) the terminal does not accept any input.  

Most gettys and such take a /dev/tty* argument, which has to be changed to
point to the serial port for a serial console. Config scripts (and
anything else) specifically using /dev/tty or /dev/console should work
fine, however. (I wouldn't recommend pointing a getty at /dev/console - we
had some issues on a headless server trying that. Easiest to point it at
/dev/ttyS0 or whatnot.)

 
 So far I have been able to debug to the point where I see that the kernel is
 receiving the characters from the serial.c driver.  But it never echos them
 or does anything else with them.  I will continue to look into this at this
 end.  
 
 I was also wondering if anyone else has seen this or if a patch is avail for
 this bug??
 
 Marc Karasek
 Sr. Firmware Engineer
 iVivity Inc
 [EMAIL PROTECTED]  
 -
 To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
---
   _.-=Disconnect=-._
| [EMAIL PROTECTED]| And Remember...
\  [EMAIL PROTECTED]  / He who controls Purple controls the Universe..
 PGP Key given on Request  Or at least the Purple parts!

-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a--? C$ ULBS*$ P L+ 
E--- W+++ N+@ o+$ K? w---+ O- M V-- PS+() PE Y+@ PGP++() t 5--- 
X-- R tv+@ b$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Your response is requested

[Disconnect]

(Sending to LKML just so nobody else flips out)

OK it wasn't just us.  Lemme reassure the admins I just forwarded it to ;)

It seems to list the hostname of whoever receives it (neat trick).

On Tue, 17 Apr 2001, Dave Zarzycki did have cause to say:

> On Tue, 17 Apr 2001 [EMAIL PROTECTED] wrote:
> ^^
> 
> Arrggg!!! Mumble... grumble... F*cking spammer using my hostname as the
> from address for sending spam...
> 
---
-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C$ ULBS*$ P+>+++ L>+ 
E--- W+++ N+@ o+>$ K? w--->+ O- M V-- PS+() PE Y+@ PGP++() t 5--- 
X-- R tv+@ b>$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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: pageable kernel-segments

[Disconnect]

On Tue, 17 Apr 2001, Heusden, Folkert van did have cause to say:

> I would think is usable (for example) for my 8MB ram laptop.
> Anyone any thoughts on this?

I'm not a kernel hacker, but I've got some thoughts on this:

1> Modules (with the autoloader) can do that for anything not necessary to
boot. (Although even modules could lose a few pages after they
load/init/etc.  Hardware setup tends to only happen once..)

2> It'd be great for embedded systems.  But you'd need a "scale" -
something along the lines of "Page this out, compress it, step on it,
forget it, we'll never need it in a hurry" up through "page this out if
you -absolutely- have to, but make it easily accessible as fast as
possible".

3> It would involve a major kernel rewrite before it was anything more
than a slowdown to a few drivers supporting it.  And there would probably
need to be some /proc method of forbidding paging on certain
(modules/segments/etc) so that, for example, people who hit the
least-likely-path (most-likely-to-page-out) on a regular basis can disable
paging of that section/module/driver/whatnot.


-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C$ ULBS*$ P+>+++ L>+ 
E--- W+++ N+@ o+>$ K? w--->+ O- M V-- PS+() PE Y+@ PGP++() t 5--- 
X-- R tv+@ b>$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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: pageable kernel-segments

[Disconnect]

On Tue, 17 Apr 2001, Heusden, Folkert van did have cause to say:

 I would think is usable (for example) for my 8MB ram laptop.
 Anyone any thoughts on this?

I'm not a kernel hacker, but I've got some thoughts on this:

1 Modules (with the autoloader) can do that for anything not necessary to
boot. (Although even modules could lose a few pages after they
load/init/etc.  Hardware setup tends to only happen once..)

2 It'd be great for embedded systems.  But you'd need a "scale" -
something along the lines of "Page this out, compress it, step on it,
forget it, we'll never need it in a hurry" up through "page this out if
you -absolutely- have to, but make it easily accessible as fast as
possible".

3 It would involve a major kernel rewrite before it was anything more
than a slowdown to a few drivers supporting it.  And there would probably
need to be some /proc method of forbidding paging on certain
(modules/segments/etc) so that, for example, people who hit the
least-likely-path (most-likely-to-page-out) on a regular basis can disable
paging of that section/module/driver/whatnot.


-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a--? C$ ULBS*$ P L+ 
E--- W+++ N+@ o+$ K? w---+ O- M V-- PS+() PE Y+@ PGP++() t 5--- 
X-- R tv+@ b$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Your response is requested

[Disconnect]

(Sending to LKML just so nobody else flips out)

OK it wasn't just us.  Lemme reassure the admins I just forwarded it to ;)

It seems to list the hostname of whoever receives it (neat trick).

On Tue, 17 Apr 2001, Dave Zarzycki did have cause to say:

 On Tue, 17 Apr 2001 [EMAIL PROTECTED] wrote:
 ^^
 
 Arrggg!!! Mumble... grumble... F*cking spammer using my hostname as the
 from address for sending spam...
 
---
-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a--? C$ ULBS*$ P L+ 
E--- W+++ N+@ o+$ K? w---+ O- M V-- PS+() PE Y+@ PGP++() t 5--- 
X-- R tv+@ b$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Athlon runtime problems

[Disconnect]

> Can the folks who are seeing crashes running athlon optimised kernels all mail
> me
> - CPU model/stepping
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 4
model name  : AMD Athlon(tm) Processor
stepping: 2
cpu MHz : 1202.743

(/proc/cpuinfo attached) 1.2G Tbird

> - Chipset

Iwill KK266, VIA KT133

> - Amount of RAM

512M PC133 amd-approved

> - /proc/mtrr output
reg00: base=0x (   0MB), size= 512MB: write-back, count=1
reg01: base=0xd000 (3328MB), size=  64MB: write-combining, count=1
reg05: base=0xd800 (3456MB), size=  64MB: write-combining, count=1

(This is from inside X on a K6 kernel. I can try to save it out from the
K7 kernel if needed.)

> - compiler used

gcc version 2.95.3 20010219 (prerelease)
debian gcc 2.95.3-5

---
   _.-==-._
| [EMAIL PROTECTED]| And Remember...
\  [EMAIL PROTECTED]  / He who controls Purple controls the Universe..
 PGP Key given on Request  Or at least the Purple parts!

-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C$ ULBS*$ P+>+++ L>+ 
E--- W+++ N+@ o+>$ K? w--->+ O- M V-- PS+() PE Y+@ PGP++() t 5--- 
X-- R tv+@ b>$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--


processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 4
model name  : AMD Athlon(tm) Processor
stepping: 2
cpu MHz : 1202.743
cache size  : 256 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 
mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips: 2398.61

Re: Problem with k7 optimizations in 2.4.x?

[Disconnect]

Blew sky high. Booted stock 2.4.3-ac3, K7 optimizations, init=/bin/sh.  
First time it went fine for quite some time (10-15 mins, find / -print,
etc) and then locked up hard on "open".  Second time, it oops'd before
hardlocking (which I copied out by hand.) The oops and decode are
attached.

On Fri, 13 Apr 2001, Alan Cox did have cause to say:

> > On the iwill mobo? (I haven't heard of this problem on other
> > motherboards.)
> 
> Im not using an Iwill board. I'm using an AMD751/756 based board and an old
> 'Uncle Fester' reference board.
> 
---
   _.-==-._
| [EMAIL PROTECTED]| And Remember...
\  [EMAIL PROTECTED]  / He who controls Purple controls the Universe..
 PGP Key given on Request  Or at least the Purple parts!

-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C$ ULBS*$ P+>+++ L>+ 
E--- W+++ N+@ o+>$ K? w--->+ O- M V-- PS+() PE Y+@ PGP++() t 5--- 
X-- R tv+@ b>$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--


ksymoops 2.3.7 on i686 2.4.3.  Options used
 -v vmlinux (specified)
 -K (specified)
 -L (specified)
 -O (specified)
 -m System.map (specified)
 -1

EIP: c023873a
Call Trace: [] [] [] [] [] 
[] [] [] []
Code: 0f 6f 03 0f e7 06 0f 6f 4b 08 0f e7 4e 08 0f 6f 53 10 0f e7
Using defaults from ksymoops -t elf32-i386 -a i386

Trace; c0238847 
Trace; c0121295 
Trace; c0121a3b 
Trace; c0110d18 
Trace; c0110bc0 
Trace; c011be74 
Trace; c011ce4a 
Trace; c011d1f5 
Trace; c010714c 
Code;   Before first symbol
 <_EIP>:
Code;   Before first symbol
   0:   0f 6f 03  movq   (%ebx),%mm0
Code;  0003 Before first symbol
   3:   0f e7 06  movntq %mm0,(%esi)
Code;  0006 Before first symbol
   6:   0f 6f 4b 08   movq   0x8(%ebx),%mm1
Code;  000a Before first symbol
   a:   0f e7 4e 08   movntq %mm1,0x8(%esi)
Code;  000e Before first symbol
   e:   0f 6f 53 10   movq   0x10(%ebx),%mm2
Code;  0012 Before first symbol
  12:   0f e7 00  movntq %mm0,(%eax)



null pointer defref 
EIP: c023873a
pgd entry d904 - 
pmd entry d904 - 
pmd not present!

Call Trace: [] [] [] [] [] 
[] [] [] []
Code: 0f 6f 03 0f e7 06 0f 6f 4b 08 0f e7 4e 08 0f 6f 53 10 0f e7

Re: Problem with k7 optimizations in 2.4.x?

[Disconnect]

Blew sky high. Booted stock 2.4.3-ac3, K7 optimizations, init=/bin/sh.  
First time it went fine for quite some time (10-15 mins, find / -print,
etc) and then locked up hard on "open".  Second time, it oops'd before
hardlocking (which I copied out by hand.) The oops and decode are
attached.

On Fri, 13 Apr 2001, Alan Cox did have cause to say:

  On the iwill mobo? (I haven't heard of this problem on other
  motherboards.)
 
 Im not using an Iwill board. I'm using an AMD751/756 based board and an old
 'Uncle Fester' reference board.
 
---
   _.-=Disconnect=-._
| [EMAIL PROTECTED]| And Remember...
\  [EMAIL PROTECTED]  / He who controls Purple controls the Universe..
 PGP Key given on Request  Or at least the Purple parts!

-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a--? C$ ULBS*$ P L+ 
E--- W+++ N+@ o+$ K? w---+ O- M V-- PS+() PE Y+@ PGP++() t 5--- 
X-- R tv+@ b$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--


ksymoops 2.3.7 on i686 2.4.3.  Options used
 -v vmlinux (specified)
 -K (specified)
 -L (specified)
 -O (specified)
 -m System.map (specified)
 -1

EIP: c023873a
Call Trace: [c0238847] [c0121295] [c0121a3b] [c0110d18] [c0110bc0] 
[c011be74] [c011ce4a] [c011d1f5] [c010714c]
Code: 0f 6f 03 0f e7 06 0f 6f 4b 08 0f e7 4e 08 0f 6f 53 10 0f e7
Using defaults from ksymoops -t elf32-i386 -a i386

Trace; c0238847 mmx_copy_page+37/40
Trace; c0121295 do_wp_page+1c5/230
Trace; c0121a3b handle_mm_fault+9b/d0
Trace; c0110d18 do_page_fault+158/440
Trace; c0110bc0 do_page_fault+0/440
Trace; c011be74 rm_sig_from_queue+14/20
Trace; c011ce4a do_sigaction+ba/120
Trace; c011d1f5 sys_rt_sigaction+75/d0
Trace; c010714c error_code+34/3c
Code;   Before first symbol
 _EIP:
Code;   Before first symbol
   0:   0f 6f 03  movq   (%ebx),%mm0
Code;  0003 Before first symbol
   3:   0f e7 06  movntq %mm0,(%esi)
Code;  0006 Before first symbol
   6:   0f 6f 4b 08   movq   0x8(%ebx),%mm1
Code;  000a Before first symbol
   a:   0f e7 4e 08   movntq %mm1,0x8(%esi)
Code;  000e Before first symbol
   e:   0f 6f 53 10   movq   0x10(%ebx),%mm2
Code;  0012 Before first symbol
  12:   0f e7 00  movntq %mm0,(%eax)



null pointer defref 
EIP: c023873a
pgd entry d904 - 
pmd entry d904 - 
pmd not present!

Call Trace: [c0238847] [c0121295] [c0121a3b] [c0110d18] [c0110bc0] 
[c011be74] [c011ce4a] [c011d1f5] [c010714c]
Code: 0f 6f 03 0f e7 06 0f 6f 4b 08 0f e7 4e 08 0f 6f 53 10 0f e7

Re: Athlon runtime problems

[Disconnect]

 Can the folks who are seeing crashes running athlon optimised kernels all mail
 me
 - CPU model/stepping
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 4
model name  : AMD Athlon(tm) Processor
stepping: 2
cpu MHz : 1202.743

(/proc/cpuinfo attached) 1.2G Tbird

 - Chipset

Iwill KK266, VIA KT133

 - Amount of RAM

512M PC133 amd-approved

 - /proc/mtrr output
reg00: base=0x (   0MB), size= 512MB: write-back, count=1
reg01: base=0xd000 (3328MB), size=  64MB: write-combining, count=1
reg05: base=0xd800 (3456MB), size=  64MB: write-combining, count=1

(This is from inside X on a K6 kernel. I can try to save it out from the
K7 kernel if needed.)

 - compiler used

gcc version 2.95.3 20010219 (prerelease)
debian gcc 2.95.3-5

---
   _.-=Disconnect=-._
| [EMAIL PROTECTED]| And Remember...
\  [EMAIL PROTECTED]  / He who controls Purple controls the Universe..
 PGP Key given on Request  Or at least the Purple parts!

-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a--? C$ ULBS*$ P L+ 
E--- W+++ N+@ o+$ K? w---+ O- M V-- PS+() PE Y+@ PGP++() t 5--- 
X-- R tv+@ b$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--


processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 4
model name  : AMD Athlon(tm) Processor
stepping: 2
cpu MHz : 1202.743
cache size  : 256 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 
mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips: 2398.61

Re: Problem with k7 optimizations in 2.4.x?

[Disconnect]

On the iwill mobo? (I haven't heard of this problem on other
motherboards.)

I'll grab the latest -ac today and give it a try this evening. 

(Just for reference, the system is the Iwill kk266, 1.2G tbird, 512M
pc133, ata66 drive - everything has AMD-approved stickers and nothing is
overclocked.)

On Fri, 13 Apr 2001, Alan Cox did have cause to say:

> > settings or what, but whenever I try to run a 2.4.x kernel on my machine 
> > with k7 optimizations the computer will never fully boot and seems to 
> > give random errors about being "unable to handle kernel NULL pointer 
> > dereference at virtual address " and other errors.
> 
> I run the K7 optimisations in 2.4.x-ac built with gcc 2.96-69 or later with no
> problems. I've not tested them with egcs-1.1.2. The earlier 2.4.* had problems
> on later Athlons which have both fxsave and movntq/sfence. That was fixed a 
> while back tho
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
---
   _.-==-._
| [EMAIL PROTECTED]| And Remember...
\  [EMAIL PROTECTED]  / He who controls Purple controls the Universe..
 PGP Key given on Request  Or at least the Purple parts!

-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C$ ULBS*$ P+>+++ L>+ 
E--- W+++ N+@ o+>$ K? w--->+ O- M V-- PS+() PE Y+@ PGP++() t 5--- 
X-- R tv+@ b>$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Problem with k7 optimizations in 2.4.x?

[Disconnect]

Several of us on the list had the same/similar problems.  AFAIK the only
fix at this point is to run w/ no more than K6 optimizations.

Check the archives for
-> Only 10 MB/sec with via 82c686b (towards the end of the thread)
-> thunderbird 1.2G + kk266 + 2.4.x oops

It seems to be something wierd with the way memory is handled on the iwill
board.

On Fri, 13 Apr 2001, Moses Mcknight did have cause to say:

> Hi,
> 
> I don't know if this is a problem with my hardware setup or config 
> settings or what, but whenever I try to run a 2.4.x kernel on my machine 
> with k7 optimizations the computer will never fully boot and seems to 
> give random errors about being "unable to handle kernel NULL pointer 
> dereference at virtual address " and other errors.
> This has happened with the debian 2.4.2 package and my own 
> compilings of 2.4.3, 2.4.3-ac4, and 2.4.3-ac5.  If I compile it with 586 
> optimizations it works fine.
> My hardware is as follows: Athlon/Thunderbird 850 Mhz CPU,
> Iwill KK266 Mobo. (uses VIA kt133a chipset and 686b southbridge) with 
> the latest BIOS update from fullon3d.com which is supposed to fix the 
> data corruption problem, 256 MB SDRAM and IBM DTLA-307060 HD.
> 
> Thanks for any info/help.
> Moses
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
---
   _.-==-._
| [EMAIL PROTECTED]| And Remember...
\  [EMAIL PROTECTED]  / He who controls Purple controls the Universe..
 PGP Key given on Request  Or at least the Purple parts!

-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C$ ULBS*$ P+>+++ L>+ 
E--- W+++ N+@ o+>$ K? w--->+ O- M V-- PS+() PE Y+@ PGP++() t 5--- 
X-- R tv+@ b>$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Problem with k7 optimizations in 2.4.x?

[Disconnect]

Several of us on the list had the same/similar problems.  AFAIK the only
fix at this point is to run w/ no more than K6 optimizations.

Check the archives for
- Only 10 MB/sec with via 82c686b (towards the end of the thread)
- thunderbird 1.2G + kk266 + 2.4.x oops

It seems to be something wierd with the way memory is handled on the iwill
board.

On Fri, 13 Apr 2001, Moses Mcknight did have cause to say:

 Hi,
 
 I don't know if this is a problem with my hardware setup or config 
 settings or what, but whenever I try to run a 2.4.x kernel on my machine 
 with k7 optimizations the computer will never fully boot and seems to 
 give random errors about being "unable to handle kernel NULL pointer 
 dereference at virtual address " and other errors.
 This has happened with the debian 2.4.2 package and my own 
 compilings of 2.4.3, 2.4.3-ac4, and 2.4.3-ac5.  If I compile it with 586 
 optimizations it works fine.
 My hardware is as follows: Athlon/Thunderbird 850 Mhz CPU,
 Iwill KK266 Mobo. (uses VIA kt133a chipset and 686b southbridge) with 
 the latest BIOS update from fullon3d.com which is supposed to fix the 
 data corruption problem, 256 MB SDRAM and IBM DTLA-307060 HD.
 
 Thanks for any info/help.
 Moses
 
 -
 To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
---
   _.-=Disconnect=-._
| [EMAIL PROTECTED]| And Remember...
\  [EMAIL PROTECTED]  / He who controls Purple controls the Universe..
 PGP Key given on Request  Or at least the Purple parts!

-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a--? C$ ULBS*$ P L+ 
E--- W+++ N+@ o+$ K? w---+ O- M V-- PS+() PE Y+@ PGP++() t 5--- 
X-- R tv+@ b$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Problem with k7 optimizations in 2.4.x?

[Disconnect]

On the iwill mobo? (I haven't heard of this problem on other
motherboards.)

I'll grab the latest -ac today and give it a try this evening. 

(Just for reference, the system is the Iwill kk266, 1.2G tbird, 512M
pc133, ata66 drive - everything has AMD-approved stickers and nothing is
overclocked.)

On Fri, 13 Apr 2001, Alan Cox did have cause to say:

  settings or what, but whenever I try to run a 2.4.x kernel on my machine 
  with k7 optimizations the computer will never fully boot and seems to 
  give random errors about being "unable to handle kernel NULL pointer 
  dereference at virtual address " and other errors.
 
 I run the K7 optimisations in 2.4.x-ac built with gcc 2.96-69 or later with no
 problems. I've not tested them with egcs-1.1.2. The earlier 2.4.* had problems
 on later Athlons which have both fxsave and movntq/sfence. That was fixed a 
 while back tho
 
 -
 To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
---
   _.-=Disconnect=-._
| [EMAIL PROTECTED]| And Remember...
\  [EMAIL PROTECTED]  / He who controls Purple controls the Universe..
 PGP Key given on Request  Or at least the Purple parts!

-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a--? C$ ULBS*$ P L+ 
E--- W+++ N+@ o+$ K? w---+ O- M V-- PS+() PE Y+@ PGP++() t 5--- 
X-- R tv+@ b$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: All processes hung under 2.4.3

[Disconnect]

Althought I was unable to do any debugging, I found the same thing earlier
today.  Syslog showed everything normal (uptimed reports, MARK, etc) and
ctrl-sysrq worked, but it had frozen hard.  I was using xlock, and it was
stopped in the middle of an opengl saver.  I had suspected it was related
to the nvidia drivers (I just got AGP enabled yesterday) but this looks a
lot like what I was seeing.

(On a side note, does anyone know if the K7 optimizations have been fixed
for those of us using the KK266 mobo?)

On Sun, 08 Apr 2001, Steven Walter did have cause to say:

> Earlier today, I tried to unlock xscreensaver on my desktop.  After
> typing in the password, it said "Checking..." and then hung.  In
> response, I hit Ctrl+Alt+Bksp, which killed X.  However, gdm did not
> restart X.  I tried logging in on the console, but none of them were
> responsive; characters would echo, but nothing else.
> 
> In hopes of finding the problem, I entered kdb, and did a bta.  All
> processes were hung in exactly the same spot, schedule+0x268!  This code
> is as follows:
> 
> 0xc0110d50 :jne0xc0110d7e 
> 0xc0110d52 :test   %eax,%eax
> 0xc0110d54 :jne0xc0110d72 
> 0xc0110d56 :mov0xffe4(%ecx),%edx
> 0xc0110d59 :test   %edx,%edx
> 0xc0110d5b :je 0xc0110d7e 
> 0xc0110d5d :mov0xfff0(%ecx),%eax
> 0xc0110d60 :cmp0xfff0(%ebp),%eax
> 0xc0110d63 :je 0xc0110d69 
> 0xc0110d65 :test   %eax,%eax
> 0xc0110d67 :jne0xc0110d6a 
> 0xc0110d69 :inc%edx
> 0xc0110d6a :add$0x14,%edx
> 0xc0110d6d :sub0x24(%esi),%edx
> 0xc0110d70 :jmp0xc0110d7e 
> 
> Additionally, I did a "ps" in kdb and found dozens of "cron" and "sh"
> started.  I suspect that these processes were somehow related to the
> lockup, as the machine should've been idle for hours, and no cron jobs
> were scheduled for the time.
> 
> The captured "bta" is availible if anyone is interested.  I don't know
> of a way to reproduce this offhand.
> -- 
> -Steven
> Freedom is the freedom to say that two plus two equals four.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
---
   _.-==-._
| [EMAIL PROTECTED]| And Remember...
\  [EMAIL PROTECTED]  / He who controls Purple controls the Universe..
 PGP Key given on Request  Or at least the Purple parts!

-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C$ ULBS*$ P+>+++ L>+ 
E--- W+++ N+@ o+>$ K? w--->+ O- M V-- PS+() PE Y+@ PGP++() t 5--- 
X-- R tv+@ b>$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: All processes hung under 2.4.3

[Disconnect]

Althought I was unable to do any debugging, I found the same thing earlier
today.  Syslog showed everything normal (uptimed reports, MARK, etc) and
ctrl-sysrq worked, but it had frozen hard.  I was using xlock, and it was
stopped in the middle of an opengl saver.  I had suspected it was related
to the nvidia drivers (I just got AGP enabled yesterday) but this looks a
lot like what I was seeing.

(On a side note, does anyone know if the K7 optimizations have been fixed
for those of us using the KK266 mobo?)

On Sun, 08 Apr 2001, Steven Walter did have cause to say:

 Earlier today, I tried to unlock xscreensaver on my desktop.  After
 typing in the password, it said "Checking..." and then hung.  In
 response, I hit Ctrl+Alt+Bksp, which killed X.  However, gdm did not
 restart X.  I tried logging in on the console, but none of them were
 responsive; characters would echo, but nothing else.
 
 In hopes of finding the problem, I entered kdb, and did a bta.  All
 processes were hung in exactly the same spot, schedule+0x268!  This code
 is as follows:
 
 0xc0110d50 schedule+252:jne0xc0110d7e schedule+298
 0xc0110d52 schedule+254:test   %eax,%eax
 0xc0110d54 schedule+256:jne0xc0110d72 schedule+286
 0xc0110d56 schedule+258:mov0xffe4(%ecx),%edx
 0xc0110d59 schedule+261:test   %edx,%edx
 0xc0110d5b schedule+263:je 0xc0110d7e schedule+298
 0xc0110d5d schedule+265:mov0xfff0(%ecx),%eax
 0xc0110d60 schedule+268:cmp0xfff0(%ebp),%eax
 0xc0110d63 schedule+271:je 0xc0110d69 schedule+277
 0xc0110d65 schedule+273:test   %eax,%eax
 0xc0110d67 schedule+275:jne0xc0110d6a schedule+278
 0xc0110d69 schedule+277:inc%edx
 0xc0110d6a schedule+278:add$0x14,%edx
 0xc0110d6d schedule+281:sub0x24(%esi),%edx
 0xc0110d70 schedule+284:jmp0xc0110d7e schedule+298
 
 Additionally, I did a "ps" in kdb and found dozens of "cron" and "sh"
 started.  I suspect that these processes were somehow related to the
 lockup, as the machine should've been idle for hours, and no cron jobs
 were scheduled for the time.
 
 The captured "bta" is availible if anyone is interested.  I don't know
 of a way to reproduce this offhand.
 -- 
 -Steven
 Freedom is the freedom to say that two plus two equals four.
 -
 To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
---
   _.-=Disconnect=-._
| [EMAIL PROTECTED]| And Remember...
\  [EMAIL PROTECTED]  / He who controls Purple controls the Universe..
 PGP Key given on Request  Or at least the Purple parts!

-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a--? C$ ULBS*$ P L+ 
E--- W+++ N+@ o+$ K? w---+ O- M V-- PS+() PE Y+@ PGP++() t 5--- 
X-- R tv+@ b$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

thunderbird 1.2G + kk266 + 2.4.x oops and crash

[Disconnect]

Long and short is I have a new mobo/cpu/ram (see below) that runs great
under Win98 and passes memtest86 (3 extended runs as pc133/cas2, 3
standard runs as pc100/cas3) but oops's almost immediately under Linux
2.4.x (2.4.2 and 2.4.1 at the least.)

With a few rare exceptions (usually kupdated) all of the oops's are in
kswapd (I can manually decode the call stack/etc if someone lets me know
which info they need and confirms for me real quick how to get all the
info out.  I do have the system.map on another machine, so just a
pointer/url/etc is cool.)

I have tried a couple of kernel builds, with no change.  HD access doesn't
seem to affect it (at least, e2fsck on a 10 gig partition doesn't bomb)
but doing actual work does.  (Work like, say, booting w/o init=/bin/sh ;)
..)

Hardware list:
1.2G AMD Thunderbird
Iwill kk266 (not ide-raid) mobo, via apollo kt133a - specs url below)
2 256M pc133/cas2 amd-approved dimms
new amd-approved power supply (bios and windows list voltages/cooling as
reasonable)
bunch of pci cards that don't seem to affect things either way (only one I
haven't pulled is voodoo3, since there is no onboard video)

Mobo is jumpered to 100mhz FSB (which is correct for the chip) and
multiplier/voltage/etc is set to 'auto'.

Things tried:
memtest86, passed
win98, runs fine
set speed down (1150 and 1100), no change
set ide to paranoid (noautotune, no dma, no blockmode, etc), no change
bang head on wall, no change


Full mobo specs:
http://www.iwillusa.com/products/spec.asp?ModelName=KK266=

Any help much appreciated.

---
-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C$ ULBS*$ P+>+++ L>+ 
E--- W+++ N+@ o+>$ K? w--->+ O- M V-- PS+() PE Y+@ PGP++() t 5--- 
X-- R tv+@ b>$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

thunderbird 1.2G + kk266 + 2.4.x oops and crash

[Disconnect]

Long and short is I have a new mobo/cpu/ram (see below) that runs great
under Win98 and passes memtest86 (3 extended runs as pc133/cas2, 3
standard runs as pc100/cas3) but oops's almost immediately under Linux
2.4.x (2.4.2 and 2.4.1 at the least.)

With a few rare exceptions (usually kupdated) all of the oops's are in
kswapd (I can manually decode the call stack/etc if someone lets me know
which info they need and confirms for me real quick how to get all the
info out.  I do have the system.map on another machine, so just a
pointer/url/etc is cool.)

I have tried a couple of kernel builds, with no change.  HD access doesn't
seem to affect it (at least, e2fsck on a 10 gig partition doesn't bomb)
but doing actual work does.  (Work like, say, booting w/o init=/bin/sh ;)
..)

Hardware list:
1.2G AMD Thunderbird
Iwill kk266 (not ide-raid) mobo, via apollo kt133a - specs url below)
2 256M pc133/cas2 amd-approved dimms
new amd-approved power supply (bios and windows list voltages/cooling as
reasonable)
bunch of pci cards that don't seem to affect things either way (only one I
haven't pulled is voodoo3, since there is no onboard video)

Mobo is jumpered to 100mhz FSB (which is correct for the chip) and
multiplier/voltage/etc is set to 'auto'.

Things tried:
memtest86, passed
win98, runs fine
set speed down (1150 and 1100), no change
set ide to paranoid (noautotune, no dma, no blockmode, etc), no change
bang head on wall, no change


Full mobo specs:
http://www.iwillusa.com/products/spec.asp?ModelName=KK266SupportID=

Any help much appreciated.

---
-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a--? C$ ULBS*$ P L+ 
E--- W+++ N+@ o+$ K? w---+ O- M V-- PS+() PE Y+@ PGP++() t 5--- 
X-- R tv+@ b$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/