alienware hardware

alienware hardware

[Yaroslav Halchenko]

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

Re: alienware hardware

[Yaroslav Halchenko]

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

Re: alienware hardware

[Yaroslav Halchenko]

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

Re: alienware hardware

[Yaroslav Halchenko]

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

Re: alienware hardware

[Yaroslav Halchenko]

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

Re: alienware hardware - memory problem?

[Yaroslav Halchenko]

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

Re: alienware hardware - memory problem?

[Helge Hafting]

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

Re: alienware hardware - memory problem?

[Yaroslav Halchenko]

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

Re: alienware hardware - memory problem?

[Helge Hafting]

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

Re: alienware hardware - memory problem?

[Yaroslav Halchenko]

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

Re: alienware hardware - memory problem?

[Helge Hafting]

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