Dear kernel-people,
Please give me hints
How can I track down next problem: we've got a new laptop from alienware
(Septa model seems to me). We've tried kernels shipped with debian:
2.4.26 and 2.6.6 but then I moved to vanila 2.6.7-bk7
and problem persisted: during boot after some point it becomes way too
slow : like it is running 100MHz, but checking
/proc/acpi/processor/CPU1/* showed that it didn't switch to any
throtelling mode or anything like that. Just it runs the process in "R"
mode on 99.9% cpu utilization user mode:
CPU states: 99.8% user, 0.2% system, 0.0% nice, 0.0% idle
It seems that it slows down right after starting work with IDE... though
I can be wrong. Probably it is linked to the fact that most of the
devices are not recognized by the kernel and it uses some bad defaults?
Also I've tried to specify idebus=66 because it was complaining about
setting default 33 but it didn't quite help...
Here are some detailes about the machine:
alien:/proc# lspci
00:00.0 Host bridge: Intel Corp.: Unknown device 3580 (rev 02)
00:00.1 System peripheral: Intel Corp.: Unknown device 3584 (rev 02)
00:00.3 System peripheral: Intel Corp.: Unknown device 3585 (rev 02)
00:02.0 VGA compatible controller: Intel Corp.: Unknown device 3582 (rev 02)
00:02.1 Display controller: Intel Corp.: Unknown device 3582 (rev 02)
00:1d.0 USB Controller: Intel Corp.: Unknown device 24c2 (rev 03)
00:1d.1 USB Controller: Intel Corp.: Unknown device 24c4 (rev 03)
00:1d.2 USB Controller: Intel Corp.: Unknown device 24c7 (rev 03)
00:1d.7 USB Controller: Intel Corp.: Unknown device 24cd (rev 03)
00:1e.0 PCI bridge: Intel Corp. 82820 820 (Camino 2) Chipset PCI (-M) (rev 83)
00:1f.0 ISA bridge: Intel Corp.: Unknown device 24cc (rev 03)
00:1f.1 IDE interface: Intel Corp.: Unknown device 24ca (rev 03)
00:1f.3 SMBus: Intel Corp.: Unknown device 24c3 (rev 03)
00:1f.5 Multimedia audio controller: Intel Corp.: Unknown device 24c5 (rev 03)
00:1f.6 Modem: Intel Corp.: Unknown device 24c6 (rev 03)
01:00.0 CardBus bridge: O2 Micro, Inc.: Unknown device 6972
01:01.0 FireWire (IEEE 1394): VIA Technologies, Inc. OHCI Compliant IEEE 1394 Host Controller (rev 80)
01:02.0 Network controller: Intel Corp.: Unknown device 4220 (rev 05)
01:08.0 Ethernet controller: Intel Corp.: Unknown device 103a (rev 83)
alien:/proc# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 9
model name : Intel(R) Pentium(R) M processor 1700MHz
stepping : 5
cpu MHz : 1693.651
cache size : 1024 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 tm pbe tm2 est
bogomips : 3350.52
alien:/proc# cat /proc/interrupts
CPU0
0: 2224762 IO-APIC-edge timer
1: 1741 IO-APIC-edge i8042
8: 3 IO-APIC-edge rtc
9: 13 IO-APIC-level acpi
12: 9473 IO-APIC-edge i8042
14: 4784 IO-APIC-edge ide0
15: 13 IO-APIC-edge ide1
16: 0 IO-APIC-level uhci_hcd
17: 0 IO-APIC-level Intel 82801DB-ICH4
18: 0 IO-APIC-level uhci_hcd
19: 0 IO-APIC-level uhci_hcd
20: 13049 IO-APIC-level eth0
23: 0 IO-APIC-level ehci_hcd
NMI: 0
LOC: 2224931
ERR: 0
MIS: 0
--
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers
Office (973) 353-5440 x263
Ph.D. Student CS Dept. NJIT
Key http://www.onerussian.com/gpg-yoh.asc
GPG fingerprint 3BB6 E124 0643 A615 6F00 6854 8D11 4563 75C0 24C8
please have a look at
http://www.onerussian.com/Linux/bugs/alien/topout
which has 4 runs of top in it
Also I put more relevant information in
http://www.onerussian.com/Linux/bugs/alien/
Spasibki Zaranee
--
Yarik
On Thu, Jun 24, 2004 at 11:15:56PM +0300, Denis Vlasenko wrote:
> On Thursday 24 June 2004 22:10, Yaroslav Halchenko wrote:
> > Dear kernel-people,
> > Please give me hints
> > How can I track down next problem: we've got a new laptop from alienware
> > (Septa model seems to me). We've tried kernels shipped with debian:
> > 2.4.26 and 2.6.6 but then I moved to vanila 2.6.7-bk7
> > and problem persisted: during boot after some point it becomes way too
> > slow : like it is running 100MHz, but checking
> > /proc/acpi/processor/CPU1/* showed that it didn't switch to any
> > throtelling mode or anything like that. Just it runs the process in "R"
> > mode on 99.9% cpu utilization user mode:
> > CPU states: 99.8% user, 0.2% system, 0.0% nice, 0.0% idle
> full top please?
--
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers
Office (973) 353-5440 x263
Ph.D. Student CS Dept. NJIT
Key http://www.onerussian.com/gpg-yoh.asc
GPG fingerprint 3BB6 E124 0643 A615 6F00 6854 8D11 4563 75C0 24C8
How about a top output without dpkg installing or removing stuff?
> -----Original Message-----
> From: Yaroslav Halchenko [mailto:[email protected]]
> Sent: June 24, 2004 3:26 PM
> To: Denis Vlasenko
> Cc: linux kernel mailing list
> Subject: Re: alienware hardware
>
>
> please have a look at
> http://www.onerussian.com/Linux/bugs/alien/topout
>
> which has 4 runs of top in it
>
>
> Also I put more relevant information in
> http://www.onerussian.com/Linux/bugs/alien/
>
> Spasibki Zaranee
>
> --
> Yarik
>
>
> On Thu, Jun 24, 2004 at 11:15:56PM +0300, Denis Vlasenko wrote:
> > On Thursday 24 June 2004 22:10, Yaroslav Halchenko wrote:
> > > Dear kernel-people,
>
> > > Please give me hints
>
> > > How can I track down next problem: we've got a new laptop
> from alienware
> > > (Septa model seems to me). We've tried kernels shipped
> with debian:
> > > 2.4.26 and 2.6.6 but then I moved to vanila 2.6.7-bk7
> > > and problem persisted: during boot after some point it
> becomes way too
> > > slow : like it is running 100MHz, but checking
> > > /proc/acpi/processor/CPU1/* showed that it didn't switch to any
> > > throtelling mode or anything like that. Just it runs the
> process in "R"
> > > mode on 99.9% cpu utilization user mode:
> > > CPU states: 99.8% user, 0.2% system, 0.0% nice, 0.0% idle
>
> > full top please?
> --
> Yaroslav Halchenko
> Research Assistant, Psychology Department, Rutgers
> Office (973) 353-5440 x263
> Ph.D. Student CS Dept. NJIT
> Key http://www.onerussian.com/gpg-yoh.asc
> GPG fingerprint 3BB6 E124 0643 A615 6F00 6854 8D11 4563 75C0 24C8
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
it is seems to be more general problem, because it slows down not only
dpkg process - booting on 2.4.26 kernel takes about 5 minutes to
complete and of cause no dpkg is involved in that process.
I took dpkg as just single example, I don't what to try else on...
bogomips reports about 50% of what is in /proc/cpuinfo, so it looks
normal... I'm suspecting IDE, so it looks like when app has to work with
HDD then it slows down although HDD bulb doesn't report an activity....
but I might be wrong. btw - I will put hdparm as well on the
webpage
We are about to setup X on that beast and I will try may be some other
programs... suggestions?
--
Yarik
On Thu, Jun 24, 2004 at 11:58:55PM +0300, Denis Vlasenko wrote:
> On Thursday 24 June 2004 23:26, Yaroslav Halchenko wrote:
> > please have a look at
> > http://www.onerussian.com/Linux/bugs/alien/topout
> > which has 4 runs of top in it
> > Also I put more relevant information in
> > http://www.onerussian.com/Linux/bugs/alien/
> > Spasibki Zaranee
> PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND [K [0m
> 1501 root 25 0 25072 17M 13612 R 67.5 1.7 1:03 dpkg [K
> 1509 root 19 0 2060 1016 1852 R 25.8 0.0 0:00 top [K
> So, dpkg is misbehaving. Not a kernel problem.
> Do a
> # strace -p 1501
> and you'll se what's going on
--
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers
Office (973) 353-5440 x263
Ph.D. Student CS Dept. NJIT
Key http://www.onerussian.com/gpg-yoh.asc
GPG fingerprint 3BB6 E124 0643 A615 6F00 6854 8D11 4563 75C0 24C8
On Thu, Jun 24, 2004 at 11:58:55PM +0300, Denis Vlasenko wrote:
> Do a
> # strace -p 1501
> and you'll se what's going on
can you please help me to understand the dump?
time strace -p 2586
Process 2586 attached - interrupt to quit
brk(0) = 0x8dff000
brk(0x8e21000) = 0x8e21000
brk(0) = 0x8e21000
brk(0x8e43000) = 0x8e43000
brk(0) = 0x8e43000
brk(0x8e65000) = 0x8e65000
brk(0) = 0x8e65000
brk(0x8e87000) = 0x8e87000
brk(0) = 0x8e87000
brk(0x8ea9000) = 0x8ea9000
brk(0) = 0x8ea9000
brk(0x8ecb000) = 0x8ecb000
brk(0) = 0x8ecb000
brk(0x8eed000) = 0x8eed000
brk(0) = 0x8eed000
brk(0x8f0f000) = 0x8f0f000
brk(0) = 0x8f0f000
brk(0x8f30000) = 0x8f30000
brk(0) = 0x8f30000
brk(0x8f52000) = 0x8f52000
Process 2586 detached
real 0m6.927s
user 0m0.032s
sys 0m0.004s
if I dump longer than the rest kinda flies so it is slows down just
after
open("/var/lib/dpkg/available", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=12398100, ...}) = 0
mmap2(NULL, 12398100, PROT_READ, MAP_SHARED, 4, 0) = 0x40157000
brk(0) = 0x840e000
brk(0x8430000) = 0x8430000
brk(0) = 0x8430000
....
I will check once more when it 'delays'
--
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers
Office (973) 353-5440 x263
Ph.D. Student CS Dept. NJIT
Key http://www.onerussian.com/gpg-yoh.asc
GPG fingerprint 3BB6 E124 0643 A615 6F00 6854 8D11 4563 75C0 24C8
Thank you for replying
do you mean while resting?
here it is
http://www.onerussian.com/Linux/bugs/alien/toplazy
if during some other application running - just say which to try :-)
--
Yarik
On Thu, Jun 24, 2004 at 03:56:13PM -0500, Chad Kitching wrote:
> How about a top output without dpkg installing or removing stuff?
> > -----Original Message-----
> > From: Yaroslav Halchenko [mailto:[email protected]]
> > Sent: June 24, 2004 3:26 PM
> > To: Denis Vlasenko
> > Cc: linux kernel mailing list
> > Subject: Re: alienware hardware
> > please have a look at
> > http://www.onerussian.com/Linux/bugs/alien/topout
> > which has 4 runs of top in it
> > Also I put more relevant information in
> > http://www.onerussian.com/Linux/bugs/alien/
> > Spasibki Zaranee
> > --
> > Yarik
> > On Thu, Jun 24, 2004 at 11:15:56PM +0300, Denis Vlasenko wrote:
> > > On Thursday 24 June 2004 22:10, Yaroslav Halchenko wrote:
> > > > Dear kernel-people,
> > > > Please give me hints
> > > > How can I track down next problem: we've got a new laptop
> > from alienware
> > > > (Septa model seems to me). We've tried kernels shipped
> > with debian:
> > > > 2.4.26 and 2.6.6 but then I moved to vanila 2.6.7-bk7
> > > > and problem persisted: during boot after some point it
> > becomes way too
> > > > slow : like it is running 100MHz, but checking
> > > > /proc/acpi/processor/CPU1/* showed that it didn't switch to any
> > > > throtelling mode or anything like that. Just it runs the
> > process in "R"
> > > > mode on 99.9% cpu utilization user mode:
> > > > CPU states: 99.8% user, 0.2% system, 0.0% nice, 0.0% idle
> > > full top please?
> > --
> > Yaroslav Halchenko
> > Research Assistant, Psychology Department, Rutgers
> > Office (973) 353-5440 x263
> > Ph.D. Student CS Dept. NJIT
> > Key http://www.onerussian.com/gpg-yoh.asc
> > GPG fingerprint 3BB6 E124 0643 A615 6F00 6854 8D11 4563 75C0 24C8
> > -
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
--
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers
Office (973) 353-5440 x263
Ph.D. Student CS Dept. NJIT
Key http://www.onerussian.com/gpg-yoh.asc
GPG fingerprint 3BB6 E124 0643 A615 6F00 6854 8D11 4563 75C0 24C8
I remember I've tried to boot 2.6.6 kernel included with debian (they
have pretty much everything in modules) with pci=noacpi and acpi=off
options... it didn't help - it was slow as hell...
I will try again with them and this kernel shortly. Thanx for advice
--
Yarik
On Thu, Jun 24, 2004 at 04:42:33PM -0500, Chad Kitching wrote:
> Have you tried booting with noapic, nolapic, noioapic and/or acpi=off?
> Unfortunately since you compiled all your drivers into the kernel,
> asking you to try without loading any of them won't work without a
> recompile.
> > -----Original Message-----
> > From: Yaroslav Halchenko [mailto:[email protected]]
> > Sent: June 24, 2004 4:10 PM
> > Subject: Re: alienware hardware
> > it is seems to be more general problem, because it slows down not only
> > dpkg process - booting on 2.4.26 kernel takes about 5 minutes to
> > complete and of cause no dpkg is involved in that process.
> > I took dpkg as just single example, I don't what to try else on...
> > bogomips reports about 50% of what is in /proc/cpuinfo, so it looks
> > normal... I'm suspecting IDE, so it looks like when app has
> > to work with
> > HDD then it slows down although HDD bulb doesn't report an
> > activity....
> > but I might be wrong. btw - I will put hdparm as well on the
> > webpage
> > We are about to setup X on that beast and I will try may be some other
> > programs... suggestions?
--
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers
Office (973) 353-5440 x263
Ph.D. Student CS Dept. NJIT
Key http://www.onerussian.com/gpg-yoh.asc
GPG fingerprint 3BB6 E124 0643 A615 6F00 6854 8D11 4563 75C0 24C8
just once again and I will stop before I try with noioapic and acpi=off:
when I did strace on ps auxw it spends second or two again on mmap2
whenever it doesn't do that on any other machine
here is strace with relative timestamps (strace -r) of ps auxw
3003 0.001784 open("/boot/System.map-2.6.7-bk7", O_RDONLY|O_NONBLOCK|O_NOCTTY) = 6
3003 0.001171 fstat64(6, {st_mode=S_IFREG|0644, st_size=932887, ...}) = 0
3003 0.001598 mmap2(NULL, 932888, PROT_READ|PROT_WRITE, MAP_PRIVATE, 6, 0) = 0x40163000
3003 0.001156 close(6) = 0
3003 1.930769 mmap2(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40247000
3003 1.322821 open("/proc", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 6
3003 0.001124 fstat64(6, {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
On Thu, Jun 24, 2004 at 05:26:00PM -0400, Yaroslav Halchenko wrote:
> On Thu, Jun 24, 2004 at 11:58:55PM +0300, Denis Vlasenko wrote:
> > Do a
> > # strace -p 1501
> > and you'll se what's going on
> can you please help me to understand the dump?
> time strace -p 2586
> Process 2586 attached - interrupt to quit
> brk(0) = 0x8dff000
> brk(0x8e21000) = 0x8e21000
> brk(0) = 0x8e21000
> brk(0x8e43000) = 0x8e43000
> brk(0) = 0x8e43000
> brk(0x8e65000) = 0x8e65000
> brk(0) = 0x8e65000
> brk(0x8e87000) = 0x8e87000
> brk(0) = 0x8e87000
> brk(0x8ea9000) = 0x8ea9000
> brk(0) = 0x8ea9000
> brk(0x8ecb000) = 0x8ecb000
> brk(0) = 0x8ecb000
> brk(0x8eed000) = 0x8eed000
> brk(0) = 0x8eed000
> brk(0x8f0f000) = 0x8f0f000
> brk(0) = 0x8f0f000
> brk(0x8f30000) = 0x8f30000
> brk(0) = 0x8f30000
> brk(0x8f52000) = 0x8f52000
> Process 2586 detached
> real 0m6.927s
> user 0m0.032s
> sys 0m0.004s
> if I dump longer than the rest kinda flies so it is slows down just
> after
> open("/var/lib/dpkg/available", O_RDONLY) = 4
> fstat64(4, {st_mode=S_IFREG|0644, st_size=12398100, ...}) = 0
> mmap2(NULL, 12398100, PROT_READ, MAP_SHARED, 4, 0) = 0x40157000
> brk(0) = 0x840e000
> brk(0x8430000) = 0x8430000
> brk(0) = 0x8430000
> ....
> I will check once more when it 'delays'
--
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers
Office (973) 353-5440 x263
Ph.D. Student CS Dept. NJIT
Key http://www.onerussian.com/gpg-yoh.asc
GPG fingerprint 3BB6 E124 0643 A615 6F00 6854 8D11 4563 75C0 24C8
Have you tried booting with noapic, nolapic, noioapic and/or acpi=off?
Unfortunately since you compiled all your drivers into the kernel,
asking you to try without loading any of them won't work without a
recompile.
> -----Original Message-----
> From: Yaroslav Halchenko [mailto:[email protected]]
> Sent: June 24, 2004 4:10 PM
> Subject: Re: alienware hardware
>
>
> it is seems to be more general problem, because it slows down not only
> dpkg process - booting on 2.4.26 kernel takes about 5 minutes to
> complete and of cause no dpkg is involved in that process.
>
> I took dpkg as just single example, I don't what to try else on...
> bogomips reports about 50% of what is in /proc/cpuinfo, so it looks
> normal... I'm suspecting IDE, so it looks like when app has
> to work with
> HDD then it slows down although HDD bulb doesn't report an
> activity....
> but I might be wrong. btw - I will put hdparm as well on the
> webpage
>
> We are about to setup X on that beast and I will try may be some other
> programs... suggestions?
>
I boot it with all the options you specified.
problem persists :-/
dmesg as well as lspci and interrupts is at
http://www.onerussian.com/Linux/bugs/alien/noacpi/
help help... please help :-)
Sincerely
Yarik
On Thu, Jun 24, 2004 at 05:49:23PM -0400, Yaroslav Halchenko wrote:
> I remember I've tried to boot 2.6.6 kernel included with debian (they
> have pretty much everything in modules) with pci=noacpi and acpi=off
> options... it didn't help - it was slow as hell...
> I will try again with them and this kernel shortly. Thanx for advice
--
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers
Office (973) 353-5440 x263
Ph.D. Student CS Dept. NJIT
Key http://www.onerussian.com/gpg-yoh.asc
GPG fingerprint 3BB6 E124 0643 A615 6F00 6854 8D11 4563 75C0 24C8
because slow down seems to be linked to memory: brk(0) takes on average
0.5-1.5 second, I've decided to run silly memtest...
I have around 1GB total on that beast, I turned off swap and did memtest
1G
kernel killed the task with reporting:
Out of Memory: Killed process 1336 (memtest).
memtest: page allocation failure. order:0, mode:0xd2
[<c0140781>] __alloc_pages+0x2da/0x34a
[<c014c8f5>] do_anonymous_page+0x71/0x1d8
[<c014cabf>] do_no_page+0x63/0x398
[<c014aa06>] pte_alloc_map+0xa6/0xe7
[<c014d010>] handle_mm_fault+0xfe/0x1af
[<c014b79d>] get_user_pages+0x154/0x40b
[<c014d1b1>] make_pages_present+0x8c/0xa6
[<c014d5fb>] mlock_fixup+0xb7/0xc7
[<c014d6e8>] do_mlock+0xdd/0xea
[<c014d792>] sys_mlock+0x9d/0xa3
[<c0105b63>] syscall_call+0x7/0xb
memtest: page allocation failure. order:0, mode:0x1d2
[<c0140781>] __alloc_pages+0x2da/0x34a
[<c0143846>] do_page_cache_readahead+0x15d/0x1b9
[<c013d316>] filemap_nopage+0x337/0x395
[<c014cb21>] do_no_page+0xc5/0x398
[<c014aa06>] pte_alloc_map+0xa6/0xe7
[<c014d010>] handle_mm_fault+0xfe/0x1af
[<c0117c3e>] do_page_fault+0x325/0x50d
[<c01191ff>] wake_up_process+0x1e/0x22
[<c01f865a>] rwsem_wake+0xc2/0x144
[<c014d9c0>] .text.lock.mlock+0x1a/0x7e
[<c0117919>] do_page_fault+0x0/0x50d
[<c01065ed>] error_code+0x2d/0x38
last block 3 times and then
VM: killing process memtest
is that normal?
--
Yarik
On Thu, Jun 24, 2004 at 05:58:57PM -0400, Yaroslav Halchenko wrote:
> just once again and I will stop before I try with noioapic and acpi=off:
> when I did strace on ps auxw it spends second or two again on mmap2
> whenever it doesn't do that on any other machine
> here is strace with relative timestamps (strace -r) of ps auxw
> 3003 0.001784 open("/boot/System.map-2.6.7-bk7", O_RDONLY|O_NONBLOCK|O_NOCTTY) = 6
> 3003 0.001171 fstat64(6, {st_mode=S_IFREG|0644, st_size=932887, ...}) = 0
> 3003 0.001598 mmap2(NULL, 932888, PROT_READ|PROT_WRITE, MAP_PRIVATE, 6, 0) = 0x40163000
> 3003 0.001156 close(6) = 0
> 3003 1.930769 mmap2(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40247000
> 3003 1.322821 open("/proc", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 6
> 3003 0.001124 fstat64(6, {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
> On Thu, Jun 24, 2004 at 05:26:00PM -0400, Yaroslav Halchenko wrote:
> > On Thu, Jun 24, 2004 at 11:58:55PM +0300, Denis Vlasenko wrote:
> > > Do a
> > > # strace -p 1501
> > > and you'll se what's going on
> > can you please help me to understand the dump?
> > time strace -p 2586
> > Process 2586 attached - interrupt to quit
> > brk(0) = 0x8dff000
> > brk(0x8e21000) = 0x8e21000
> > brk(0) = 0x8e21000
> > brk(0x8e43000) = 0x8e43000
> > brk(0) = 0x8e43000
> > brk(0x8e65000) = 0x8e65000
> > brk(0) = 0x8e65000
> > brk(0x8e87000) = 0x8e87000
> > brk(0) = 0x8e87000
> > brk(0x8ea9000) = 0x8ea9000
> > brk(0) = 0x8ea9000
> > brk(0x8ecb000) = 0x8ecb000
> > brk(0) = 0x8ecb000
> > brk(0x8eed000) = 0x8eed000
> > brk(0) = 0x8eed000
> > brk(0x8f0f000) = 0x8f0f000
> > brk(0) = 0x8f0f000
> > brk(0x8f30000) = 0x8f30000
> > brk(0) = 0x8f30000
> > brk(0x8f52000) = 0x8f52000
> > Process 2586 detached
> > real 0m6.927s
> > user 0m0.032s
> > sys 0m0.004s
> > if I dump longer than the rest kinda flies so it is slows down just
> > after
> > open("/var/lib/dpkg/available", O_RDONLY) = 4
> > fstat64(4, {st_mode=S_IFREG|0644, st_size=12398100, ...}) = 0
> > mmap2(NULL, 12398100, PROT_READ, MAP_SHARED, 4, 0) = 0x40157000
> > brk(0) = 0x840e000
> > brk(0x8430000) = 0x8430000
> > brk(0) = 0x8430000
> > ....
> > I will check once more when it 'delays'
--
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers
Office (973) 353-5440 x263
Ph.D. Student CS Dept. NJIT
Key http://www.onerussian.com/gpg-yoh.asc
GPG fingerprint 3BB6 E124 0643 A615 6F00 6854 8D11 4563 75C0 24C8
Yaroslav Halchenko wrote:
>because slow down seems to be linked to memory: brk(0) takes on average
>0.5-1.5 second, I've decided to run silly memtest...
>I have around 1GB total on that beast, I turned off swap and did memtest
>1G
>
>
Memory. Could it be the good old MTRR problem?
Try "cat /proc/mtrr" and check that _all_ ordinary memory
is covered by a write-back mtrr.
Having most of the memory covered lacking a little at the top only
is not good enough - you'll see a major slowdown as linux tend to
use the topmost memory most and that will be very slow without
a MTRR.
If it indeed is a mtrr problem, confirm it by booting with mem=<low number>
and see that the machine is faster when not using the "slow" memory.
After that, get a bios upgrade or echo something useable
into /proc/mtrr
Helge Hafting
He hey - you're the boss!!!!
It helped - 'mem=512M' made the beast fast :-)
Now we just will mangle with /proc/mtrr :-)
THANX AGAIN!
Sincerely
Yarik
On Fri, Jun 25, 2004 at 10:54:43AM +0200, Helge Hafting wrote:
> Yaroslav Halchenko wrote:
> >because slow down seems to be linked to memory: brk(0) takes on average
> >0.5-1.5 second, I've decided to run silly memtest...
> >I have around 1GB total on that beast, I turned off swap and did memtest
> >1G
> Memory. Could it be the good old MTRR problem?
> Try "cat /proc/mtrr" and check that _all_ ordinary memory
> is covered by a write-back mtrr.
> Having most of the memory covered lacking a little at the top only
> is not good enough - you'll see a major slowdown as linux tend to
> use the topmost memory most and that will be very slow without
> a MTRR.
> If it indeed is a mtrr problem, confirm it by booting with mem=<low number>
> and see that the machine is faster when not using the "slow" memory.
> After that, get a bios upgrade or echo something useable
> into /proc/mtrr
> Helge Hafting
--
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers
Office (973) 353-5440 x263
Ph.D. Student CS Dept. NJIT
Key http://www.onerussian.com/gpg-yoh.asc
GPG fingerprint 3BB6 E124 0643 A615 6F00 6854 8D11 4563 75C0 24C8
On Fri, Jun 25, 2004 at 12:20:16PM -0400, Yaroslav Halchenko wrote:
> He hey - you're the boss!!!!
> It helped - 'mem=512M' made the beast fast :-)
>
> Now we just will mangle with /proc/mtrr :-)
>
> THANX AGAIN!
>
Glad to be of help. I hope the /proc/mtrr stuff works out, it is
nice to use _all_ the memory?. How much is it?
Don't forget the complaint to the vendor. The only way to get
permanently rid of this sort of problem is when the vendors get
enough reactions to sloppy bioses. Don't be silent just because
you found a solution, you shouldn't really have to in this case.
Also check if there is a newer BIOS around. :-)
Helge Hafting
On Sat, Jun 26, 2004 at 02:07:38PM +0200, Helge Hafting wrote:
> On Fri, Jun 25, 2004 at 12:20:16PM -0400, Yaroslav Halchenko wrote:
> Glad to be of help. I hope the /proc/mtrr stuff works out, it is
> nice to use _all_ the memory?. How much is it?
1GB RAM. I've found somewhere that guy did 'disable=X' with X for all
lines in mtrr (we have 6) and then just overrides first with 1Gb of
write-back and then some amount for video (64M for instance) with
uncachable. I just didn't have time to try yet :-)
> Don't forget the complaint to the vendor. The only way to get
> permanently rid of this sort of problem is when the vendors get
> enough reactions to sloppy bioses. Don't be silent just because
> you found a solution, you shouldn't really have to in this case.
I'm not sure if vendor would respect such complaint because alienware
supports only windows and Windows doesn't have such problem seems to me.
Anyway how to complain in the right way?
'BIOS errornessly fills Memory Type Range Registers with too many
memory ranges with wrong caching strategies' is it what is happening?
> Also check if there is a newer BIOS around. :-)
that might be usefull :-)
--
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers
Office (973) 353-5440 x263
Ph.D. Student CS Dept. NJIT
Key http://www.onerussian.com/gpg-yoh.asc
GPG fingerprint 3BB6 E124 0643 A615 6F00 6854 8D11 4563 75C0 24C8
On Sat, Jun 26, 2004 at 11:45:34AM -0400, Yaroslav Halchenko wrote:
> On Sat, Jun 26, 2004 at 02:07:38PM +0200, Helge Hafting wrote:
> > On Fri, Jun 25, 2004 at 12:20:16PM -0400, Yaroslav Halchenko wrote:
> > Glad to be of help. I hope the /proc/mtrr stuff works out, it is
> > nice to use _all_ the memory?. How much is it?
> 1GB RAM. I've found somewhere that guy did 'disable=X' with X for all
> lines in mtrr (we have 6) and then just overrides first with 1Gb of
> write-back and then some amount for video (64M for instance) with
> uncachable. I just didn't have time to try yet :-)
>
> > Don't forget the complaint to the vendor. The only way to get
> > permanently rid of this sort of problem is when the vendors get
> > enough reactions to sloppy bioses. Don't be silent just because
> > you found a solution, you shouldn't really have to in this case.
> I'm not sure if vendor would respect such complaint because alienware
> supports only windows and Windows doesn't have such problem seems to me.
> Anyway how to complain in the right way?
>
Remember, you're not the only linux user in the world. :-)
If everybody with trouble complain, then they get enough complaints
that it matters. It doesn't work if everybody thinks the're alone
and do nothing. Note that linux is the fastest growing OS these days.
You can also let them know before you purchase. When getting your next
machine, consider one that claims linux support. They exist - even
laptops. And if you get something else, let them know. If you
inquire about a machine - ask about linux support. Salesmen getting
a lot of that will take note. The linux market isn't the biggest
but cutting off 5%/10% of the market for no reason is bad business.
Linux support is easy - they don't have to do support, just sell
a box that works.
Bring a knoppix CD when looking at machines in shops - then you
can verify that they work without obvious snags like that mtrr bug.
> 'BIOS errornessly fills Memory Type Range Registers with too many
> memory ranges with wrong caching strategies' is it what is happening?
>
About how to complain - be constructive. Tell them that the problem is
serious and makes the machine work much slower than the competition,
but that it is easily fixable by setting the mtrr's up right in the bios.
You may also want to tell them that several other vendor have had
this problem - and fixed it by issuing a bios upgrade.
> > Also check if there is a newer BIOS around. :-)
> that might be usefull :-)
Helge Hafting