Math-emu kills the kernel on Athlon64 X2

Math-emu kills the kernel on Athlon64 X2

[Jesper Juhl]

Hi,

If I enable the math emulator in 2.6.18-rc7-git2 (only version I've
tried this with) and then boot the kernel with "no387" then I only get
as far as lilo's "...Booting the kernel." message and then the system
hangs.

The kernel is a 32bit kernel build for K8 and my CPU is a Athlon64 X2 4400+

If I boot the same kernel without the "no387" option, then it boots
and runs just fine, so it seems the math emulator code is lethal on
newer CPU's :-(

Now, I need some help debugging this. The crash happens very early and
doesn't result in anything printed to the screen (I guess it's too
early to call printk()) - How on earth can I get a lead on what's
going wrong?  Any help would be appreciated.

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: Math-emu kills the kernel on Athlon64 X2

[Linus Torvalds]

On Tue, 19 Sep 2006, Jesper Juhl wrote:
> 
> If I enable the math emulator in 2.6.18-rc7-git2 (only version I've
> tried this with) and then boot the kernel with "no387" then I only get
> as far as lilo's "...Booting the kernel." message and then the system
> hangs.

I'm wondering if it tries to use the MMX/XMM stuff for memcpy and friends. 

I'm also wondering why you'd be doing what you seem to try to be doing in 
the first place ;)

Basically, "no387" doesn't seem to disable any of the fancier FPU 
features, even though it obviously should. If you ask for math emulation, 
you'll get emulation faults for _all_ of the modern MMX stuff too (which 
we don't do). 

It's entirely possible that nobody has ever tested this combination.

		Linus

Re: Math-emu kills the kernel on Athlon64 X2

[Jesper Juhl]

On 19/09/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Tue, 19 Sep 2006, Jesper Juhl wrote:
> >
> > If I enable the math emulator in 2.6.18-rc7-git2 (only version I've
> > tried this with) and then boot the kernel with "no387" then I only get
> > as far as lilo's "...Booting the kernel." message and then the system
> > hangs.
>
> I'm wondering if it tries to use the MMX/XMM stuff for memcpy and friends.
>
> I'm also wondering why you'd be doing what you seem to try to be doing in
> the first place ;)
>
Simply to try and find bugs. If we have a math emulator and it's
selectable for my CPU type, then it should damn well work ;-)

> Basically, "no387" doesn't seem to disable any of the fancier FPU
> features, even though it obviously should. If you ask for math emulation,
> you'll get emulation faults for _all_ of the modern MMX stuff too (which
> we don't do).
>
Hmm, I guess that could be the problem. The emulator should disable
any stuff which it's not able to handle. I've not actually looked very
much at the emulator code yet, so I didn't realize it didn't disable
what it couldn't handle, but getting it to do that sounds like a
sensible first step.

> It's entirely possible that nobody has ever tested this combination.
>
That was my thought as well, which is exactely why I chose to try it -
thinking that it might expose some bugs in math-emu or elsewhere.


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: Math-emu kills the kernel on Athlon64 X2

[Linus Torvalds]

On Tue, 19 Sep 2006, Jesper Juhl wrote:
> On 19/09/06, Linus Torvalds <torvalds@osdl.org> wrote:
> > 
> > Basically, "no387" doesn't seem to disable any of the fancier FPU
> > features, even though it obviously should. If you ask for math emulation,
> > you'll get emulation faults for _all_ of the modern MMX stuff too (which
> > we don't do).
> > 
> Hmm, I guess that could be the problem. The emulator should disable
> any stuff which it's not able to handle. I've not actually looked very
> much at the emulator code yet, so I didn't realize it didn't disable
> what it couldn't handle, but getting it to do that sounds like a
> sensible first step.

I would guess that we might notice, for example, that the CPU supports 
FXSR (fxsave/fxrestor) through looking at cpuid, and then we have, for 
example:

    arch/i386/kernel/cpu/common.c: cpu_init() ->
	arch/i386/kernel/i387.c: mxcsr_feature_mask_init() ->


        if (cpu_has_fxsr) {
                memset(&current->thread.i387.fxsave, 0, sizeof(struct i387_fxsave_struct));
                asm volatile("fxsave %0" : : "m" (current->thread.i387.fxsave));
		...

ie we will do one of the fancy new instructions from kernel space (very 
early), because this path at no point even bothers to check whether it is 
supposed to even use hw FP at all.

You can try booting with "no387 nofxsr" to get rid of at least _that_ 
particular issue, but there might be other cases like that in the MMX 
code, for example ("nofxsr" should disable both the FXSR and XMM 
capabilities as far as the kernel is concerned).

If that works (or gets you further), we should just make "no387" disable 
FXSR by itself. 

Worth testing, and you can do it without even recompiling the kernel, 
since we already have that kernel command line flag.

		Linus

Re: Math-emu kills the kernel on Athlon64 X2

[Jesper Juhl]

On 19/09/06, Linus Torvalds <torvalds@osdl.org> wrote:
[...]
>
> You can try booting with "no387 nofxsr" to get rid of at least _that_
> particular issue, but there might be other cases like that in the MMX
> code, for example ("nofxsr" should disable both the FXSR and XMM
> capabilities as far as the kernel is concerned).
>
> If that works (or gets you further), we should just make "no387" disable
> FXSR by itself.
>
> Worth testing, and you can do it without even recompiling the kernel,
> since we already have that kernel command line flag.
>

Booting with: vga=normal no387 nofxsr
gets me no forther.   These are all the messages I get:

 boot: 2.6.18rc7git2 vga=normal no387 nofxsr
 Loading 2.6.18rc7git2...................................
 BIOS data check successful
 Uncompressing Linux... Ok, booting the kernel.

And then the system hangs and requires a power cycle.

So unfortunately that does't help much :-(


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: Math-emu kills the kernel on Athlon64 X2

[Linus Torvalds]

On Tue, 19 Sep 2006, Jesper Juhl wrote:
> 
> Booting with: vga=normal no387 nofxsr
> gets me no forther.   These are all the messages I get:
> 
> boot: 2.6.18rc7git2 vga=normal no387 nofxsr
> Loading 2.6.18rc7git2...................................
> BIOS data check successful
> Uncompressing Linux... Ok, booting the kernel.
> 
> And then the system hangs and requires a power cycle.
> 
> So unfortunately that does't help much :-(

Ok. The next phase is to try to figure out where it hangs, and since it 
happens very early, that's most often most easily done the hard way: add 
some code that reboots the machine, and if the machine hangs, you didn't 
reach it.

These days there's a slightly easier approach: if you enable PM_TRACE 
support (you need to enable PM and PM_DEBUG and EXPERIMENTAL to get it), 
you can do

	#include <resume-trace.h>

at the top of a file, and add a sprinkling of "TRACE_RESUME(x)" calls 
(where "x" is some integer in the range 0-15 that you can use to save off 
the iteration count in a loop, for example - leave at 0 if you're not 
interested).

And then, when it hangs, once you reboot into the same kernel (without the 
"no387", so that it works ;), it should tell you where the last 
trace-point was fairly early in the bootup dmesg's.

(It _will_ screw up your time-of-day clock in the process, though, which 
is why tracing is so hard to enable on purpose ;)

		Linus

Re: Math-emu kills the kernel on Athlon64 X2

[Sergio Monteiro Basto]

[-- Attachment #1: Type: text/plain, Size: 469 bytes --]

On Tue, 2006-09-19 at 00:18 +0200, Jesper Juhl wrote:
> Hi,
> 
> If I enable the math emulator in 2.6.18-rc7-git2 (only version I've
> tried this with) and then boot the kernel with "no387" then I only get
> as far as lilo's "...Booting the kernel." message and then the system
> hangs.
> 

I think, math emulation is for 486 and older. 486 DX2 was the first one
who have math co processor, on earlier processor it should be disable .


-- 
Sérgio M. B.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2166 bytes --]

Re: Math-emu kills the kernel on Athlon64 X2

[Jesper Juhl]

On 19/09/06, Sergio Monteiro Basto <sergio@sergiomb.no-ip.org> wrote:
> On Tue, 2006-09-19 at 00:18 +0200, Jesper Juhl wrote:
> > Hi,
> >
> > If I enable the math emulator in 2.6.18-rc7-git2 (only version I've
> > tried this with) and then boot the kernel with "no387" then I only get
> > as far as lilo's "...Booting the kernel." message and then the system
> > hangs.
> >
>
> I think, math emulation is for 486 and older. 486 DX2 was the first one
> who have math co processor, on earlier processor it should be disable .
>
Yes, it's mainly there for CPU's that don't have a math co-processor,
but it's also there for the cases where the math co-processor is
broken or where for some other reason you may not want to use it - so
it really should work...  Sure, it may be slow as hell compared to
hardware, but if it's there and I can select it then it should at
least be functional.


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: Math-emu kills the kernel on Athlon64 X2

[Krzysztof Halasa]

Sergio Monteiro Basto <sergio@sergiomb.no-ip.org> writes:
> I think, math emulation is for 486 and older. 486 DX2 was the first one
> who have math co processor, on earlier processor it should be disable .

Actually, 486 DX had built-in FPU as well. It was missing from 486SX
(486SX + optional 487 FPU = 486DX).

For 386(DX|SX) there were 387(DX|SX) (386SX used 16-bit bus).

Many 32-bit motherboards had a socket for Weitek (3167 for 386DX or 4167
for 486). I think I remember a board with 386DX and 287 socket as well.

486DX2 meant the external clock was half the internal.
-- 
Krzysztof Halasa

Re: Math-emu kills the kernel on Athlon64 X2

[Sergio Monteiro Basto]

[-- Attachment #1: Type: text/plain, Size: 1035 bytes --]

On Tue, 2006-09-19 at 14:28 +0200, Krzysztof Halasa wrote:
> Sergio Monteiro Basto <sergio@sergiomb.no-ip.org> writes:
> > I think, math emulation is for 486 and older. 486 DX2 was the first one
> > who have math co processor, on earlier processor it should be disable .
> 
> Actually, 486 DX had built-in FPU as well. It was missing from 486SX
> (486SX + optional 487 FPU = 486DX).
> 
> For 386(DX|SX) there were 387(DX|SX) (386SX used 16-bit bus).
> 
> Many 32-bit motherboards had a socket for Weitek (3167 for 386DX or 4167
> for 486). I think I remember a board with 386DX and 287 socket as well.
> 
> 486DX2 meant the external clock was half the internal.

Fine :),  My (12 year old) 486DX2 already don't need Math-emu. I just
don't see how in a computer like that will be installed a kernel 2.6 .
So why code of math-emu isn't dropped ? 

Btw I try install a kernel 2.4 in my DX2 and works but very very slow .
I think in this type of computer should be install a kernel 2.2 . 

Thanks,
-- 
Sérgio M.B.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2166 bytes --]

Re: Math-emu kills the kernel on Athlon64 X2

[Krzysztof Halasa]

Sergio Monteiro Basto <sergio@sergiomb.no-ip.org> writes:

> Btw I try install a kernel 2.4 in my DX2 and works but very very slow .
> I think in this type of computer should be install a kernel 2.2 . 

I think it's a RAM problem. Most 386DX and early 486 boards allowed
32 MB (using 4 MB modules),  Linux 2.6 should run fine on such
a beast (386SX was limited to 16 MB address space). Later 486 boards
using DIMMs, I think, supported 64 MB (with caching).

Of course a "6 bogomips" 386 CPU isn't a speed daemon but in early
1990s it wasn't any faster and people were using them commonly (and,
I think, comfortably). IMHO for basic "SOHO Internet server" (mail
and such) it could be fast enough running Linux 2.6.
-- 
Krzysztof Halasa

Re: Math-emu kills the kernel on Athlon64 X2

[Andi Kleen]

"Jesper Juhl" <jesper.juhl@gmail.com> writes:

> Hi,
> 
> If I enable the math emulator in 2.6.18-rc7-git2 (only version I've
> tried this with) and then boot the kernel with "no387" then I only get
> as far as lilo's "...Booting the kernel." message and then the system
> hangs.
> 
> The kernel is a 32bit kernel build for K8 and my CPU is a Athlon64 X2 4400+

Do you have a .config? I tried it and it booted until mounting root.

-Andi

Re: Math-emu kills the kernel on Athlon64 X2

[Jesper Juhl]

On 19 Sep 2006 10:01:55 +0200, Andi Kleen <ak@suse.de> wrote:
> "Jesper Juhl" <jesper.juhl@gmail.com> writes:
>
> > Hi,
> >
> > If I enable the math emulator in 2.6.18-rc7-git2 (only version I've
> > tried this with) and then boot the kernel with "no387" then I only get
> > as far as lilo's "...Booting the kernel." message and then the system
> > hangs.
> >
> > The kernel is a 32bit kernel build for K8 and my CPU is a Athlon64 X2 4400+
>
> Do you have a .config? I tried it and it booted until mounting root.
>
Yes, I do. I'll mail it tonight when I get home from work.

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: Math-emu kills the kernel on Athlon64 X2

[Jesper Juhl]

[-- Attachment #1: Type: text/plain, Size: 31538 bytes --]

On 19 Sep 2006 10:01:55 +0200, Andi Kleen <ak@suse.de> wrote:
> "Jesper Juhl" <jesper.juhl@gmail.com> writes:
>
> > Hi,
> >
> > If I enable the math emulator in 2.6.18-rc7-git2 (only version I've
> > tried this with) and then boot the kernel with "no387" then I only get
> > as far as lilo's "...Booting the kernel." message and then the system
> > hangs.
> >
> > The kernel is a 32bit kernel build for K8 and my CPU is a Athlon64 X2 4400+
>
> Do you have a .config? I tried it and it booted until mounting root.
>

The config is attached.

I've also attached the complete dmesg output from a working boot of this kernel.

Below is the output of  scripts/ver_linux to give you an idea of the
build environment and some lspci and various other details so you can
also get a good idea about the hardware.
Hope that's enough, otherwise just ask for whatever you may need.

juhl@dragon:~/download/kernel/linux-2.6.18-rc7-git2$ scripts/ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.

Linux dragon 2.6.18-rc7-git2 #1 SMP PREEMPT Mon Sep 18 23:58:12 CEST
2006 i686 athlon-4 i386 GNU/Linux

Gnu C                  3.4.6
Gnu make               3.81
binutils               2.15.92.0.2
util-linux             2.12r
mount                  2.12r
module-init-tools      3.2.2
e2fsprogs              1.39
reiserfsprogs          3.6.19
quota-tools            3.13.
PPP                    2.4.4b1
Linux C Library        2.3.6
Dynamic linker (ldd)   2.3.6
Linux C++ Library      6.0.3
Procps                 3.2.7
Net-tools              1.60
Kbd                    1.12
Sh-utils               5.97
udev                   097
Modules Loaded         snd_seq_oss snd_seq_midi_event snd_seq
snd_pcm_oss snd_mixer_oss agpgart snd_emu10k1 snd_rawmidi
snd_ac97_codec snd_ac97_bus snd_pcm snd_seq_device snd_timer
snd_page_alloc snd_util_mem snd_hwdep evdev snd


juhl@dragon:~/download/kernel/linux-2.6.18-rc7-git2$ uname -a
Linux dragon 2.6.18-rc7-git2 #1 SMP PREEMPT Mon Sep 18 23:58:12 CEST
2006 i686 athlon-4 i386 GNU/Linux


juhl@dragon:~/download/kernel/linux-2.6.18-rc7-git2$ cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 35
model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+
stepping        : 2
cpu MHz         : 2200.196
cache size      : 1024 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
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 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext
fxsr_opt lm 3dnowext 3dnow pni lahf_lm cmp_legacy ts fid vid ttp
bogomips        : 4402.85

processor       : 1
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 35
model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+
stepping        : 2
cpu MHz         : 2200.196
cache size      : 1024 KB
physical id     : 0
siblings        : 2
core id         : 1
cpu cores       : 2
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 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext
fxsr_opt lm 3dnowext 3dnow pni lahf_lm cmp_legacy ts fid vid ttp
bogomips        : 4399.52


root@dragon:/home/juhl/download/kernel/linux-2.6.18-rc7-git2# lspci -vvx
00:00.0 Host bridge: ALi Corporation M1695 K8 Northbridge [PCI Express
and HyperTransport]
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Capabilities: [40] HyperTransport: Slave or Primary Interface
                Command: BaseUnitID=0 UnitCnt=3 MastHost- DefDir- DUL-
                Link Control 0: CFlE- CST- CFE- <LkFail- Init+ EOC-
TXO- <CRCErr=0 IsocEn- LSEn- ExtCTL- 64b-
                Link Config 0: MLWI=16bit DwFcIn- MLWO=16bit DwFcOut-
LWI=16bit DwFcInEn- LWO=16bit DwFcOutEn-
                Link Control 1: CFlE- CST- CFE- <LkFail- Init+ EOC-
TXO- <CRCErr=0 IsocEn- LSEn- ExtCTL- 64b-
                Link Config 1: MLWI=16bit DwFcIn- MLWO=16bit DwFcOut-
LWI=8bit DwFcInEn- LWO=16bit DwFcOutEn-
                Revision ID: 1.05
                Link Frequency 0: 800MHz
                Link Error 0: <Prot- <Ovfl- <EOC- CTLTm-
                Link Frequency Capability 0: 200MHz+ 300MHz- 400MHz+
500MHz- 600MHz+ 800MHz+ 1.0GHz+ 1.2GHz+ 1.4GHz- 1.6GHz- Vend-
                Feature Capability: IsocFC- LDTSTOP+ CRCTM- ECTLT- 64bA- UIDRD-
                Link Frequency 1: 800MHz
                Link Error 1: <Prot- <Ovfl- <EOC- CTLTm-
                Link Frequency Capability 1: 200MHz+ 300MHz- 400MHz+
500MHz- 600MHz+ 800MHz+ 1.0GHz+ 1.2GHz+ 1.4GHz- 1.6GHz- Vend-
                Error Handling: PFlE- OFlE- PFE- OFE- EOCFE- RFE-
CRCFE- SERRFE- CF- RE- PNFE- ONFE- EOCNFE- RNFE- CRCNFE- SERRNFE-
                Prefetchable memory behind bridge Upper: 00-00
                Bus Number: 00
        Capabilities: [5c] HyperTransport: MSI Mapping
        Capabilities: [68] HyperTransport: UnitID Clumping
        Capabilities: [74] HyperTransport: Interrupt Discovery and Configuration
        Capabilities: [7c] Message Signalled Interrupts: 64bit+
Queue=0/1 Enable-
                Address: 00000000fee00000  Data: 0000
00: b9 10 95 16 07 00 10 00 00 00 00 06 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00

00:01.0 PCI bridge: ALi Corporation PCI Express Root Port (prog-if 00
[Normal decode])
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0, Cache Line Size: 64 bytes
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
        Memory behind bridge: ff200000-ff2fffff
        Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- <SERR- <PERR-
        BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [48] Message Signalled Interrupts: 64bit+
Queue=0/1 Enable-
                Address: 00000000fee00000  Data: 0000
        Capabilities: [58] Express Root Port (Slot+) IRQ 0
                Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag+
                Device: Latency L0s <64ns, L1 <1us
                Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
                Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
                Device: MaxPayload 128 bytes, MaxReadReq 512 bytes
                Link: Supported Speed 2.5Gb/s, Width x16, ASPM L0s L1, Port 0
                Link: Latency L0s <2us, L1 <32us
                Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch-
                Link: Speed unknown, Width x1
                Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug- Surpise-
                Slot: Number 0, PowerLimit 0.000000
                Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq-
                Slot: AttnInd Off, PwrInd Off, Power-
                Root: Correctable- Non-Fatal- Fatal- PME-
        Capabilities: [7c] HyperTransport: MSI Mapping
        Capabilities: [88] HyperTransport: Revision ID: 1.05
00: b9 10 4b 52 06 01 10 00 00 00 04 06 10 00 01 00
10: 00 00 00 00 00 00 00 00 00 01 01 00 f0 00 00 00
20: 20 ff 20 ff f0 ff 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 0a 01 03 00

00:02.0 PCI bridge: ALi Corporation PCI Express Root Port (prog-if 00
[Normal decode])
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0, Cache Line Size: 64 bytes
        Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
        Memory behind bridge: ff300000-ff3fffff
        Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- <SERR- <PERR-
        BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [48] Message Signalled Interrupts: 64bit+
Queue=0/1 Enable-
                Address: 00000000fee00000  Data: 0000
        Capabilities: [58] Express Root Port (Slot+) IRQ 0
                Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag+
                Device: Latency L0s <64ns, L1 <1us
                Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
                Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
                Device: MaxPayload 128 bytes, MaxReadReq 512 bytes
                Link: Supported Speed 2.5Gb/s, Width x2, ASPM L0s L1, Port 0
                Link: Latency L0s <2us, L1 <32us
                Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch-
                Link: Speed unknown, Width x1
                Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug- Surpise-
                Slot: Number 0, PowerLimit 0.000000
                Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq-
                Slot: AttnInd Off, PwrInd Off, Power-
                Root: Correctable- Non-Fatal- Fatal- PME-
        Capabilities: [7c] HyperTransport: MSI Mapping
        Capabilities: [88] HyperTransport: Revision ID: 1.05
00: b9 10 4c 52 06 01 10 00 00 00 04 06 10 00 01 00
10: 00 00 00 00 00 00 00 00 00 02 02 00 f0 00 00 00
20: 30 ff 30 ff f0 ff 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 01 03 00

00:04.0 Host bridge: ALi Corporation M1689 K8 Northbridge [Super K8 Single Chip]
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Region 0: Memory at dc000000 (32-bit, prefetchable) [size=64M]
        Capabilities: [40] HyperTransport: Slave or Primary Interface
                Command: BaseUnitID=4 UnitCnt=1 MastHost- DefDir- DUL-
                Link Control 0: CFlE- CST- CFE- <LkFail- Init+ EOC-
TXO- <CRCErr=0 IsocEn- LSEn- ExtCTL- 64b-
                Link Config 0: MLWI=16bit DwFcIn- MLWO=8bit DwFcOut-
LWI=16bit DwFcInEn- LWO=8bit DwFcOutEn-
                Link Control 1: CFlE- CST- CFE- <LkFail+ Init- EOC+
TXO+ <CRCErr=0 IsocEn- LSEn- ExtCTL- 64b-
                Link Config 1: MLWI=8bit DwFcIn- MLWO=8bit DwFcOut-
LWI=8bit DwFcInEn- LWO=8bit DwFcOutEn-
                Revision ID: 1.04
                Link Frequency 0: 800MHz
                Link Error 0: <Prot- <Ovfl- <EOC- CTLTm-
                Link Frequency Capability 0: 200MHz+ 300MHz- 400MHz+
500MHz- 600MHz+ 800MHz+ 1.0GHz- 1.2GHz- 1.4GHz- 1.6GHz- Vend-
                Feature Capability: IsocFC- LDTSTOP+ CRCTM- ECTLT- 64bA- UIDRD-
                Link Frequency 1: 200MHz
                Link Error 1: <Prot- <Ovfl- <EOC- CTLTm-
                Link Frequency Capability 1: 200MHz- 300MHz- 400MHz-
500MHz- 600MHz- 800MHz- 1.0GHz- 1.2GHz- 1.4GHz- 1.6GHz- Vend-
                Error Handling: PFlE- OFlE- PFE- OFE- EOCFE- RFE-
CRCFE- SERRFE- CF- RE- PNFE- ONFE- EOCNFE- RNFE- CRCNFE- SERRNFE-
                Prefetchable memory behind bridge Upper: 00-00
                Bus Number: 00
        Capabilities: [60] HyperTransport: Interrupt Discovery and Configuration
        Capabilities: [80] AGP version 3.0
                Status: RQ=28 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64-
HTrans- 64bit- FW- AGP3- Rate=x1,x2,x4
                Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit-
FW- Rate=<none>
00: b9 10 89 16 06 01 10 00 00 00 00 06 00 00 00 00
10: 08 00 00 dc 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00

00:05.0 PCI bridge: ALi Corporation AGP8X Controller (prog-if 00
[Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
        Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Bus: primary=00, secondary=03, subordinate=03, sec-latency=64
        Memory behind bridge: ff400000-ff4fffff
        Prefetchable memory behind bridge: c7f00000-d7efffff
        Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort+ <SERR- <PERR-
        BridgeCtl: Parity+ SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B-
00: b9 10 46 52 07 01 20 00 00 00 04 06 00 00 01 00
10: 00 00 00 00 00 00 00 00 00 03 03 40 f0 00 20 22
20: 40 ff 40 ff f0 c7 e0 d7 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0b 00

00:06.0 PCI bridge: ALi Corporation M5249 HTT to PCI Bridge (prog-if
01 [Subtractive decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Bus: primary=00, secondary=04, subordinate=04, sec-latency=32
        I/O behind bridge: 0000d000-0000dfff
        Memory behind bridge: ff500000-ff5fffff
        Prefetchable memory behind bridge: 88000000-880fffff
        Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort+ <SERR- <PERR-
        BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
00: b9 10 49 52 07 01 00 00 00 01 04 06 00 00 01 00
10: 00 00 00 00 00 00 00 00 00 04 04 20 d0 d0 00 22
20: 50 ff 50 ff 00 88 00 88 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 00

00:07.0 ISA bridge: ALi Corporation M1563 HyperTransport South Bridge (rev 70)
        Subsystem: ASRock Incorporation Unknown device 1563
        Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0 (250ns min, 6000ns max)
00: b9 10 63 15 0f 00 00 02 70 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 49 18 63 15
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 18

00:07.1 Bridge: ALi Corporation M7101 Power Management Controller [PMU]
        Subsystem: ASRock Incorporation Unknown device 7101
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
00: b9 10 01 71 00 00 00 02 00 00 80 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 49 18 01 71
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:11.0 Ethernet controller: ALi Corporation ULi 1689,1573 integrated
ethernet. (rev 40)
        Subsystem: ASRock Incorporation Unknown device 5263
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (5000ns min, 10000ns max), Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 10
        Region 0: I/O ports at e800 [size=256]
        Region 1: Memory at ff6ffc00 (32-bit, non-prefetchable) [size=256]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: b9 10 63 52 07 01 10 02 40 00 00 02 08 20 00 00
10: 01 e8 00 00 00 fc 6f ff 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 49 18 63 52
30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 01 14 28

00:12.0 IDE interface: ALi Corporation M5229 IDE (rev c7) (prog-if 8a
[Master SecP PriP])
        Subsystem: ASRock Incorporation Unknown device 5229
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32
        Interrupt: pin A routed to IRQ 0
        Region 0: I/O ports at <ignored>
        Region 1: I/O ports at <ignored>
        Region 2: I/O ports at <ignored>
        Region 3: I/O ports at <ignored>
        Region 4: I/O ports at ff00 [size=16]
00: b9 10 29 52 05 00 a0 02 c7 8a 01 01 00 20 00 00
10: f1 01 00 00 f5 03 00 00 71 01 00 00 75 03 00 00
20: 01 ff 00 00 00 00 00 00 00 00 00 00 49 18 29 52
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00

00:13.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03)
(prog-if 10 [OHCI])
        Subsystem: ASRock Incorporation Unknown device 5237
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
        Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (20000ns max), Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at ff6fe000 (32-bit, non-prefetchable) [size=4K]
00: b9 10 37 52 17 01 a8 02 03 10 03 0c 10 20 80 00
10: 00 e0 6f ff 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 49 18 37 52
30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 01 00 50

00:13.1 USB Controller: ALi Corporation USB 1.1 Controller (rev 03)
(prog-if 10 [OHCI])
        Subsystem: ASRock Incorporation Unknown device 5237
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
        Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (20000ns max), Cache Line Size: 64 bytes
        Interrupt: pin B routed to IRQ 3
        Region 0: Memory at ff6fd000 (32-bit, non-prefetchable) [size=4K]
00: b9 10 37 52 17 01 a8 02 03 10 03 0c 10 20 80 00
10: 00 d0 6f ff 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 49 18 37 52
30: 00 00 00 00 00 00 00 00 00 00 00 00 03 02 00 50

00:13.2 USB Controller: ALi Corporation USB 1.1 Controller (rev 03)
(prog-if 10 [OHCI])
        Subsystem: ASRock Incorporation Unknown device 5237
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
        Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (20000ns max), Cache Line Size: 64 bytes
        Interrupt: pin C routed to IRQ 11
        Region 0: Memory at ff6fc000 (32-bit, non-prefetchable) [size=4K]
00: b9 10 37 52 17 01 a8 02 03 10 03 0c 10 20 80 00
10: 00 c0 6f ff 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 49 18 37 52
30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 03 00 50

00:13.3 USB Controller: ALi Corporation USB 2.0 Controller (rev 01)
(prog-if 20 [EHCI])
        Subsystem: ASRock Incorporation Unknown device 5239
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (4000ns min, 8000ns max), Cache Line Size: 64 bytes
        Interrupt: pin D routed to IRQ 5
        Region 0: Memory at ff6ff800 (32-bit, non-prefetchable) [size=256]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [58] Debug port
00: b9 10 39 52 16 01 b0 02 01 20 03 0c 10 20 80 00
10: 00 f8 6f ff 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 49 18 39 52
30: 00 00 00 00 50 00 00 00 00 00 00 00 05 04 10 20

00:18.0 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] HyperTransport Technology Configuration
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Capabilities: [80] HyperTransport: Host or Secondary Interface
                !!! Possibly incomplete decoding
                Command: WarmRst+ DblEnd-
                Link Control: CFlE- CST- CFE- <LkFail- Init+ EOC- TXO- <CRCErr=0
                Link Config: MLWI=16bit MLWO=16bit LWI=16bit LWO=16bit
                Revision ID: 1.02
00: 22 10 00 11 00 00 10 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00

00:18.1 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] Address Map
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
00: 22 10 01 11 00 00 00 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:18.2 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] DRAM Controller
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
00: 22 10 02 11 00 00 00 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:18.3 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] Miscellaneous Control
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
00: 22 10 03 11 00 00 00 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

03:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA Parhelia
AGP (rev 03) (prog-if 00 [VGA])
        Subsystem: Matrox Graphics, Inc. Parhelia 128Mb
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (4000ns min, 8000ns max), Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 5
        Region 0: Memory at c8000000 (32-bit, prefetchable) [size=128M]
        Region 1: Memory at ff4fe000 (32-bit, non-prefetchable) [size=8K]
        Expansion ROM at ff4c0000 [disabled] [size=128K]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [f0] AGP version 2.0
                Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64-
HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4
                Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit-
FW- Rate=<none>
00: 2b 10 27 05 07 00 b0 02 03 00 00 03 10 20 00 00
10: 08 00 00 c8 00 e0 4f ff 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 2b 10 40 08
30: 00 00 4c ff dc 00 00 00 00 00 00 00 05 01 10 20

04:05.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 0a)
        Subsystem: Creative Labs SBLive! 5.1 eMicro 28028
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (500ns min, 5000ns max)
        Interrupt: pin A routed to IRQ 20
        Region 0: I/O ports at d880 [size=32]
        Capabilities: [dc] Power Management version 1
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 02 11 02 00 05 01 90 02 0a 00 01 04 00 20 80 00
10: 81 d8 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 02 11 67 80
30: 00 00 00 00 dc 00 00 00 00 00 00 00 0b 01 02 14

04:05.1 Input device controller: Creative Labs SB Live! Game Port (rev 0a)
        Subsystem: Creative Labs Gameport Joystick
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32
        Region 0: I/O ports at dc00 [size=8]
        Capabilities: [dc] Power Management version 1
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 02 11 02 70 05 01 90 02 0a 00 80 09 00 20 80 00
10: 01 dc 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 02 11 20 00
30: 00 00 00 00 dc 00 00 00 00 00 00 00 00 00 00 00

04:06.0 SCSI storage controller: Adaptec AIC-7892A U160/m (rev 02)
        Subsystem: Adaptec 29160N Ultra160 SCSI Controller
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (10000ns min, 6250ns max), Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 19
        BIST result: 00
        Region 0: I/O ports at d400 [disabled] [size=256]
        Region 1: Memory at ff5ff000 (64-bit, non-prefetchable) [size=4K]
        Expansion ROM at 88000000 [disabled] [size=128K]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 05 90 80 00 16 01 b0 02 02 00 00 01 10 20 00 80
10: 01 d4 00 00 04 f0 5f ff 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 05 90 a0 62
30: 00 00 5c ff dc 00 00 00 00 00 00 00 03 01 28 19

04:07.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 42)
        Subsystem: D-Link System Inc DFE-530TX rev B
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (750ns min, 2000ns max), Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 18
        Region 0: I/O ports at d000 [size=256]
        Region 1: Memory at ff5fec00 (32-bit, non-prefetchable) [size=256]
        Expansion ROM at 88020000 [disabled] [size=64K]
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 06 11 65 30 17 01 10 02 42 00 00 02 10 20 00 00
10: 01 d0 00 00 00 ec 5f ff 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 11 01 14
30: 00 00 ff ff 40 00 00 00 00 00 00 00 0b 01 03 08


root@dragon:/home/juhl/download/kernel/linux-2.6.18-rc7-git2# cat /proc/modules
snd_seq_oss 34896 0 - Live 0xf8eef000
snd_seq_midi_event 7048 1 snd_seq_oss, Live 0xf8cef000
snd_seq 54456 4 snd_seq_oss,snd_seq_midi_event, Live 0xf8ce0000
snd_pcm_oss 46560 0 - Live 0xf8cd3000
snd_mixer_oss 16776 2 snd_pcm_oss, Live 0xf8cf8000
agpgart 31324 0 - Live 0xf8d01000
snd_emu10k1 120784 2 - Live 0xf8bd2000
snd_rawmidi 21632 1 snd_emu10k1, Live 0xf8b91000
snd_ac97_codec 95544 1 snd_emu10k1, Live 0xf8bb9000
snd_ac97_bus 2624 1 snd_ac97_codec, Live 0xf8b8f000
snd_pcm 80236 3 snd_pcm_oss,snd_emu10k1,snd_ac97_codec, Live 0xf8ba4000
snd_seq_device 7572 4 snd_seq_oss,snd_seq,snd_emu10k1,snd_rawmidi,
Live 0xf8b8c000
snd_timer 23132 3 snd_seq,snd_emu10k1,snd_pcm, Live 0xf8b85000
snd_page_alloc 8712 2 snd_emu10k1,snd_pcm, Live 0xf8b81000
snd_util_mem 4104 1 snd_emu10k1, Live 0xf887d000
snd_hwdep 8332 1 snd_emu10k1, Live 0xf8ba0000
evdev 8960 0 - Live 0xf8879000
snd 50980 13 snd_seq_oss,snd_seq,snd_pcm_oss,snd_mixer_oss,snd_emu10k1,snd_rawmidi,snd_ac97_codec,snd_pcm,snd_seq_device,snd_timer,snd_hwdep,
Live 0xf8c2a000


root@dragon:/home/juhl/download/kernel/linux-2.6.18-rc7-git2# cat /proc/ioports
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
03c0-03df : vesafb
03f2-03f5 : floppy
03f7-03f7 : floppy DIR
03f8-03ff : serial
0800-083f : 0000:00:07.1
  0800-0803 : ACPI PM1a_EVT_BLK
  0804-0805 : ACPI PM1a_CNT_BLK
  0808-080b : ACPI PM_TMR
  0810-0815 : ACPI CPU throttle
  0818-0827 : ACPI GPE0_BLK
  0830-0830 : ACPI PM2_CNT_BLK
0cf8-0cff : PCI conf1
d000-dfff : PCI Bus #04
  d000-d0ff : 0000:04:07.0
    d000-d0ff : via-rhine
  d400-d4ff : 0000:04:06.0
  d880-d89f : 0000:04:05.0
    d880-d89f : EMU10K1
  dc00-dc07 : 0000:04:05.1
e800-e8ff : 0000:00:11.0
ff00-ff0f : 0000:00:12.0


root@dragon:/home/juhl/download/kernel/linux-2.6.18-rc7-git2# cat /proc/iomem
00000000-0009f7ff : System RAM
0009f800-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c8fff : Video ROM
000c9000-000ce3ff : Adapter ROM
000f0000-000fffff : System ROM
00100000-7ffaffff : System RAM
  00100000-0032d81c : Kernel code
  0032d81d-00413b2f : Kernel data
7ffb0000-7ffbffff : ACPI Tables
7ffc0000-7ffeffff : ACPI Non-volatile Storage
7fff0000-7fffffff : reserved
88000000-880fffff : PCI Bus #04
  88000000-8801ffff : 0000:04:06.0
  88020000-8802ffff : 0000:04:07.0
c7f00000-d7efffff : PCI Bus #03
  c8000000-cfffffff : 0000:03:00.0
    c8000000-c8ffffff : vesafb
dc000000-dfffffff : 0000:00:04.0
ff200000-ff2fffff : PCI Bus #01
ff300000-ff3fffff : PCI Bus #02
ff400000-ff4fffff : PCI Bus #03
  ff4c0000-ff4dffff : 0000:03:00.0
  ff4fe000-ff4fffff : 0000:03:00.0
ff500000-ff5fffff : PCI Bus #04
  ff5fec00-ff5fecff : 0000:04:07.0
    ff5fec00-ff5fecff : via-rhine
  ff5ff000-ff5fffff : 0000:04:06.0
    ff5ff000-ff5fffff : aic7xxx
ff6fc000-ff6fcfff : 0000:00:13.2
ff6fd000-ff6fdfff : 0000:00:13.1
ff6fe000-ff6fefff : 0000:00:13.0
ff6ff800-ff6ff8ff : 0000:00:13.3
ff6ffc00-ff6ffcff : 0000:00:11.0
ff7c0000-ffffffff : reserved


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

[-- Attachment #2: config.gz --]
[-- Type: application/x-gzip, Size: 7521 bytes --]

[-- Attachment #3: dmesg-2.6.18-rc7-git2 --]
[-- Type: application/octet-stream, Size: 17262 bytes --]

Linux version 2.6.18-rc7-git2 (juhl@dragon) (gcc version 3.4.6) #1 SMP PREEMPT Mon Sep 18 23:58:12 CEST 2006
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
 BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e8000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000007ffb0000 (usable)
 BIOS-e820: 000000007ffb0000 - 000000007ffc0000 (ACPI data)
 BIOS-e820: 000000007ffc0000 - 000000007fff0000 (ACPI NVS)
 BIOS-e820: 000000007fff0000 - 0000000080000000 (reserved)
 BIOS-e820: 00000000ff7c0000 - 0000000100000000 (reserved)
1151MB HIGHMEM available.
896MB LOWMEM available.
found SMP MP-table at 000ff780
On node 0 totalpages: 524208
  DMA zone: 4096 pages, LIFO batch:0
  Normal zone: 225280 pages, LIFO batch:31
  HighMem zone: 294832 pages, LIFO batch:31
DMI 2.3 present.
ACPI: RSDP (v000 ACPIAM                                ) @ 0x000f9bb0
ACPI: RSDT (v001 A M I  OEMRSDT  0x12000506 MSFT 0x00000097) @ 0x7ffb0000
ACPI: FADT (v002 A M I  OEMFACP  0x12000506 MSFT 0x00000097) @ 0x7ffb0200
ACPI: MADT (v001 A M I  OEMAPIC  0x12000506 MSFT 0x00000097) @ 0x7ffb0390
ACPI: OEMB (v001 A M I  AMI_OEM  0x12000506 MSFT 0x00000097) @ 0x7ffc0040
ACPI: DSDT (v001  939M2 939M2150 0x00000150 INTL 0x02002026) @ 0x00000000
ACPI: PM-Timer IO Port: 0x808
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:3 APIC version 16
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 15:3 APIC version 16
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23
ACPI: IOAPIC (id[0x03] address[0xfec10000] gsi_base[24])
IOAPIC[1]: apic_id 3, version 17, address 0xfec10000, GSI 24-39
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode:  Flat.  Using 2 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 88000000 (gap: 80000000:7f7c0000)
Detected 2200.196 MHz processor.
Built 1 zonelists.  Total pages: 524208
Kernel command line: auto BOOT_IMAGE=2.6.18rc7git2 ro root=801
mapped APIC to ffffd000 (fee00000)
mapped IOAPIC to ffffc000 (fec00000)
mapped IOAPIC to ffffb000 (fec10000)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
CPU 0 irqstacks, hard=c04ad000 soft=c04ab000
PID hash table entries: 4096 (order: 12, 16384 bytes)
Console: colour dummy device 80x25
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES:    8
... MAX_LOCK_DEPTH:          30
... MAX_LOCKDEP_KEYS:        2048
... CLASSHASH_SIZE:           1024
... MAX_LOCKDEP_ENTRIES:     8192
... MAX_LOCKDEP_CHAINS:      8192
... CHAINHASH_SIZE:          4096
 memory used by lock dependency info: 696 kB
 per task-struct memory footprint: 1200 bytes
------------------------
| Locking API testsuite:
----------------------------------------------------------------------------
                                 | spin |wlock |rlock |mutex | wsem | rsem |
  --------------------------------------------------------------------------
                     A-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
                 A-B-B-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
             A-B-B-C-C-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
             A-B-C-A-B-C deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
         A-B-B-C-C-D-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
         A-B-C-D-B-D-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
         A-B-C-D-B-C-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
                    double unlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
                  initialize held:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
                 bad unlock order:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
  --------------------------------------------------------------------------
              recursive read-lock:             |  ok  |             |  ok  |
           recursive read-lock #2:             |  ok  |             |  ok  |
            mixed read-write-lock:             |  ok  |             |  ok  |
            mixed write-read-lock:             |  ok  |             |  ok  |
  --------------------------------------------------------------------------
     hard-irqs-on + irq-safe-A/12:  ok  |  ok  |  ok  |
     soft-irqs-on + irq-safe-A/12:  ok  |  ok  |  ok  |
     hard-irqs-on + irq-safe-A/21:  ok  |  ok  |  ok  |
     soft-irqs-on + irq-safe-A/21:  ok  |  ok  |  ok  |
       sirq-safe-A => hirqs-on/12:  ok  |  ok  |  ok  |
       sirq-safe-A => hirqs-on/21:  ok  |  ok  |  ok  |
         hard-safe-A + irqs-on/12:  ok  |  ok  |  ok  |
         soft-safe-A + irqs-on/12:  ok  |  ok  |  ok  |
         hard-safe-A + irqs-on/21:  ok  |  ok  |  ok  |
         soft-safe-A + irqs-on/21:  ok  |  ok  |  ok  |
    hard-safe-A + unsafe-B #1/123:  ok  |  ok  |  ok  |
    soft-safe-A + unsafe-B #1/123:  ok  |  ok  |  ok  |
    hard-safe-A + unsafe-B #1/132:  ok  |  ok  |  ok  |
    soft-safe-A + unsafe-B #1/132:  ok  |  ok  |  ok  |
    hard-safe-A + unsafe-B #1/213:  ok  |  ok  |  ok  |
    soft-safe-A + unsafe-B #1/213:  ok  |  ok  |  ok  |
    hard-safe-A + unsafe-B #1/231:  ok  |  ok  |  ok  |
    soft-safe-A + unsafe-B #1/231:  ok  |  ok  |  ok  |
    hard-safe-A + unsafe-B #1/312:  ok  |  ok  |  ok  |
    soft-safe-A + unsafe-B #1/312:  ok  |  ok  |  ok  |
    hard-safe-A + unsafe-B #1/321:  ok  |  ok  |  ok  |
    soft-safe-A + unsafe-B #1/321:  ok  |  ok  |  ok  |
    hard-safe-A + unsafe-B #2/123:  ok  |  ok  |  ok  |
    soft-safe-A + unsafe-B #2/123:  ok  |  ok  |  ok  |
    hard-safe-A + unsafe-B #2/132:  ok  |  ok  |  ok  |
    soft-safe-A + unsafe-B #2/132:  ok  |  ok  |  ok  |
    hard-safe-A + unsafe-B #2/213:  ok  |  ok  |  ok  |
    soft-safe-A + unsafe-B #2/213:  ok  |  ok  |  ok  |
    hard-safe-A + unsafe-B #2/231:  ok  |  ok  |  ok  |
    soft-safe-A + unsafe-B #2/231:  ok  |  ok  |  ok  |
    hard-safe-A + unsafe-B #2/312:  ok  |  ok  |  ok  |
    soft-safe-A + unsafe-B #2/312:  ok  |  ok  |  ok  |
    hard-safe-A + unsafe-B #2/321:  ok  |  ok  |  ok  |
    soft-safe-A + unsafe-B #2/321:  ok  |  ok  |  ok  |
      hard-irq lock-inversion/123:  ok  |  ok  |  ok  |
      soft-irq lock-inversion/123:  ok  |  ok  |  ok  |
      hard-irq lock-inversion/132:  ok  |  ok  |  ok  |
      soft-irq lock-inversion/132:  ok  |  ok  |  ok  |
      hard-irq lock-inversion/213:  ok  |  ok  |  ok  |
      soft-irq lock-inversion/213:  ok  |  ok  |  ok  |
      hard-irq lock-inversion/231:  ok  |  ok  |  ok  |
      soft-irq lock-inversion/231:  ok  |  ok  |  ok  |
      hard-irq lock-inversion/312:  ok  |  ok  |  ok  |
      soft-irq lock-inversion/312:  ok  |  ok  |  ok  |
      hard-irq lock-inversion/321:  ok  |  ok  |  ok  |
      soft-irq lock-inversion/321:  ok  |  ok  |  ok  |
      hard-irq read-recursion/123:  ok  |
      soft-irq read-recursion/123:  ok  |
      hard-irq read-recursion/132:  ok  |
      soft-irq read-recursion/132:  ok  |
      hard-irq read-recursion/213:  ok  |
      soft-irq read-recursion/213:  ok  |
      hard-irq read-recursion/231:  ok  |
      soft-irq read-recursion/231:  ok  |
      hard-irq read-recursion/312:  ok  |
      soft-irq read-recursion/312:  ok  |
      hard-irq read-recursion/321:  ok  |
      soft-irq read-recursion/321:  ok  |
-------------------------------------------------------
Good, all 218 testcases passed! |
---------------------------------
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 2071624k/2096832k available (2230k kernel code, 24072k reserved, 920k data, 212k init, 1179328k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 4402.85 BogoMIPS (lpj=2201425)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 178bfbff e3d3fbff 00000000 00000000 00000001 00000000 00000003
CPU: After vendor identify, caps: 178bfbff e3d3fbff 00000000 00000000 00000001 00000000 00000003
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 0(2) -> Core 0
CPU: After all inits, caps: 178bfbff e3d3fbff 00000000 00000410 00000001 00000000 00000003
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Checking 'hlt' instruction... OK.
Freeing SMP alternatives: 12k freed
ACPI: Core revision 20060707
CPU0: AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ stepping 02
lockdep: not fixing up alternatives.
Booting processor 1/1 eip 2000
CPU 1 irqstacks, hard=c04ae000 soft=c04ac000
Initializing CPU#1
Calibrating delay using timer specific routine.. 4399.52 BogoMIPS (lpj=2199763)
CPU: After generic identify, caps: 178bfbff e3d3fbff 00000000 00000000 00000001 00000000 00000003
CPU: After vendor identify, caps: 178bfbff e3d3fbff 00000000 00000000 00000001 00000000 00000003
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 1(2) -> Core 1
CPU: After all inits, caps: 178bfbff e3d3fbff 00000000 00000410 00000001 00000000 00000003
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ stepping 02
Total of 2 processors activated (8802.37 BogoMIPS).
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
checking TSC synchronization across 2 CPUs: 
CPU#0 had -30 usecs TSC skew, fixed it up.
CPU#1 had 30 usecs TSC skew, fixed it up.
Brought up 2 CPUs
migration_cost=393
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 3.00 entry at 0xf0031, last bus=4
PCI: Using configuration type 1
Setting up standard PCI resources
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
PCI quirk: region 0800-083f claimed by ali7101 ACPI
Boot video device is 0000:03:00.0
PCI: Transparent bridge - 0000:00:06.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P4._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HTT_._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEB1._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEB2._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 *5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *10 11 12 14 15), disabled.
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *10 11 12 14 15), disabled.
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKF] (IRQs *3 4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 10 11 12 14 15) *9
ACPI: PCI Interrupt Link [LNKP] (IRQs 3 4 *5 6 7 10 11 12 14 15)
SCSI subsystem initialized
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
PCI: Bridge: 0000:00:01.0
  IO window: disabled.
  MEM window: ff200000-ff2fffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:02.0
  IO window: disabled.
  MEM window: ff300000-ff3fffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:05.0
  IO window: disabled.
  MEM window: ff400000-ff4fffff
  PREFETCH window: c7f00000-d7efffff
PCI: Bridge: 0000:00:06.0
  IO window: d000-dfff
  MEM window: ff500000-ff5fffff
  PREFETCH window: 88000000-880fffff
ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 29 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:01.0 to 64
ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 34 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:00:02.0 to 64
PCI: Setting latency timer of device 0000:00:05.0 to 64
PCI: Setting latency timer of device 0000:00:06.0 to 64
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 65536 (order: 9, 2359296 bytes)
TCP bind hash table entries: 32768 (order: 8, 1179648 bytes)
TCP: Hash tables configured (established 65536 bind 32768)
TCP reno registered
Machine check exception polling timer started.
Initializing RT-Tester: OK
highmem bounce pool size: 64 pages
io scheduler noop registered
io scheduler cfq registered (default)
vesafb: framebuffer at 0xc8000000, mapped to 0xf8880000, using 3072k, total 16384k
vesafb: mode is 1024x768x16, linelength=2048, pages=9
vesafb: protected mode interface info at c000:7880
vesafb: pmi: set display start = c00c79d3, set palette = c00c7ab3
vesafb: pmi: ports = 
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
Console: switching to colour frame buffer device 128x48
fb0: VESA VGA frame buffer device
Real Time Clock Driver v1.12ac
Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
via-rhine.c:v1.10-LK1.4.1 July-24-2006 Written by Donald Becker
ACPI: PCI Interrupt 0000:04:07.0[A] -> GSI 22 (level, low) -> IRQ 18
eth0: VIA Rhine II at 0xff5fec00, 00:50:ba:f2:a3:1d, IRQ 18.
eth0: MII PHY found at address 8, status 0x782d advertising 01e1 Link 45e1.
ACPI: PCI Interrupt 0000:04:06.0[A] -> GSI 21 (level, low) -> IRQ 19
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
        <Adaptec 29160N Ultra160 SCSI adapter>
        aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs

  Vendor: PIONEER   Model: DVD-ROM DVD-305   Rev: 1.03
  Type:   CD-ROM                             ANSI SCSI revision: 02
 target0:0:4: Beginning Domain Validation
 target0:0:4: FAST-20 SCSI 20.0 MB/s ST (50 ns, offset 16)
 target0:0:4: Domain Validation skipping write tests
 target0:0:4: Ending Domain Validation
  Vendor: PLEXTOR   Model: CD-R   PX-W1210S  Rev: 1.01
  Type:   CD-ROM                             ANSI SCSI revision: 02
 target0:0:5: Beginning Domain Validation
 target0:0:5: FAST-20 SCSI 20.0 MB/s ST (50 ns, offset 16)
 target0:0:5: Domain Validation skipping write tests
 target0:0:5: Ending Domain Validation
  Vendor: IBM       Model: DDYS-T36950N      Rev: S96H
  Type:   Direct-Access                      ANSI SCSI revision: 03
scsi0:A:6:0: Tagged Queuing enabled.  Depth 200
 target0:0:6: Beginning Domain Validation
 target0:0:6: wide asynchronous
 target0:0:6: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 63)
 target0:0:6: Ending Domain Validation
SCSI device sda: 71687340 512-byte hdwr sectors (36704 MB)
sda: Write Protect is off
sda: Mode Sense: cb 00 00 08
SCSI device sda: drive cache: write back
SCSI device sda: 71687340 512-byte hdwr sectors (36704 MB)
sda: Write Protect is off
sda: Mode Sense: cb 00 00 08
SCSI device sda: drive cache: write back
 sda: sda1 sda2 sda3 sda4
sd 0:0:6:0: Attached scsi disk sda
sr0: scsi3-mmc drive: 16x/40x cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 0:0:4:0: Attached scsi CD-ROM sr0
sr1: scsi3-mmc drive: 32x/32x writer cd/rw xa/form2 cdda tray
sr 0:0:5:0: Attached scsi CD-ROM sr1
sr 0:0:4:0: Attached scsi generic sg0 type 5
sr 0:0:5:0: Attached scsi generic sg1 type 5
sd 0:0:6:0: Attached scsi generic sg2 type 0
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
EDAC MC: Ver: 2.0.1 Sep 18 2006
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Starting balanced_irq
Using IPI Shortcut mode
Time: acpi_pm clocksource has been installed.
input: AT Translated Set 2 keyboard as /class/input/input0
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 212k freed
Write protecting the kernel read-only data: 368k
input: ImExPS/2 Generic Explorer Mouse as /class/input/input1
Adding 763076k swap on /dev/sda3.  Priority:-1 extents:1 across:763076k
EXT3 FS on sda1, internal journal
ACPI: PCI Interrupt 0000:04:05.0[A] -> GSI 20 (level, low) -> IRQ 20
Linux agpgart interface v0.101 (c) Dave Jones
ReiserFS: sda2: found reiserfs format "3.6" with standard journal
ReiserFS: sda2: using ordered data mode
ReiserFS: sda2: journal params: device sda2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: sda2: checking transaction log (sda2)
ReiserFS: sda2: Using r5 hash to sort names
ReiserFS: sda4: found reiserfs format "3.6" with standard journal
ReiserFS: sda4: using ordered data mode
ReiserFS: sda4: journal params: device sda4, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: sda4: checking transaction log (sda4)
ReiserFS: sda4: Using r5 hash to sort names
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1

Re: Math-emu kills the kernel on Athlon64 X2

[Linus Torvalds]

On Tue, 19 Sep 2006, Jesper Juhl wrote:
> 
> The config is attached.

Can you try without SMP, and with CONFIG_X86_GENERIC (the latter to make 
sure that we don't do any static optimizations: right now you've told the 
compile system that you're compiling for an Opteron, and while I _think_ 
all the SSE optimizations are dynamic at run-time, I haven't checked 
extensively.

Re: Math-emu kills the kernel on Athlon64 X2

[Jesper Juhl]

On 20/09/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Tue, 19 Sep 2006, Jesper Juhl wrote:
> >
> > The config is attached.
>
> Can you try without SMP, and with CONFIG_X86_GENERIC

Done. The result is exactely the same as before. The kernel boots and
runs just fine except when I add "no387" to the boot options, then it
hangs.


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: Math-emu kills the kernel on Athlon64 X2

[Jesper Juhl]

On 20/09/06, Jesper Juhl <jesper.juhl@gmail.com> wrote:
> On 20/09/06, Linus Torvalds <torvalds@osdl.org> wrote:
> >
> >
> > On Tue, 19 Sep 2006, Jesper Juhl wrote:
> > >
> > > The config is attached.
> >
> > Can you try without SMP, and with CONFIG_X86_GENERIC
>
> Done. The result is exactely the same as before. The kernel boots and
> runs just fine except when I add "no387" to the boot options, then it
> hangs.
>
I just tried building the kernel for 486 as well - no luck with
"no387" with that one either.

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

[PATCH/RFC] Math-emu kills the kernel on Athlon64 X2

[Randy Dunlap]

On Tue, 19 Sep 2006 15:01:08 -0700 (PDT) Linus Torvalds wrote:

> On Tue, 19 Sep 2006, Jesper Juhl wrote:
> > 
> > The config is attached.
> 
> Can you try without SMP, and with CONFIG_X86_GENERIC (the latter to make 
> sure that we don't do any static optimizations: right now you've told the 
> compile system that you're compiling for an Opteron, and while I _think_ 
> all the SSE optimizations are dynamic at run-time, I haven't checked 
> extensively.

I had no trouble reproducing the boot failure (on Pentium-M), then
I tried TRACE_RESUME().  Nifty, but not really needed here since
earlyprintk worked and contained the fault messages:

[   16.776035] Kernel command line: auto BOOT_IMAGE=lin2618-jj ro root=808 resume=/dev/sda6 splash=silent showopts netconsole=6665@192.168.0.104/eth0,6666@192.168.0.101/00:13:20:e3:97:02 console=ttyS0,115200n8 console=tty0 earlyprintk=serial,ttyS0,115200 initcall_debug debug no387 nofxsr
[   16.801176] netconsole: local port 6665
[   16.804916] netconsole: local IP 192.168.0.104
[   16.809321] netconsole: interface eth0
[   16.813037] netconsole: remote port 6666
[   16.816926] netconsole: remote IP 192.168.0.101
[   16.821418] netconsole: remote ethernet address 00:13:20:e3:97:02
[   16.827663] Enabling fast FPU save and restore... done.
[   16.832704] Enabling unmasked SIMD FPU exception support... done.
[   16.838753] Initializing CPU#0
[   16.841784] math_emulate: 0060:c01062dd
[   16.845579] Kernel panic - not syncing: Math emulation needed in kernel

But CONFIG_MATH_EMULATION=y, so what now?

The panic message is for this:

  else if ( FPU_CS == __KERNEL_CS )
    {
      printk("math_emulate: %04x:%08lx\n",FPU_CS,FPU_EIP);
      panic("Math emulation needed in kernel");
    }

but that doesn't look like a real problem.

Linus mentioned CPU feature bits.  The message log above didn't
make me feel good about them.  Sure enough, we are playing with
features before reading the feature bits.

So, I have a patch that now boots with "no387 nofxsr".
It mixes some sauce into the spaghetti code during init.
The system is somewhat usable.  Network device (tg3) works,
but USB complains about everything and the X driver won't load,
so I don't think that the patch is finished.  :)

and I strongly wish that bugs.h didn't contain ("hide") so
much code.

---
From: Randy Dunlap <rdunlap@xenotime.net>

Math (floating point) emulation has been broken for awhile.
The primary reason for this is that CPU feature bits have
not been read/set yet when they are tested/used, due to
ordering changes in init/main.c.

Changes here:
This is a twisted maze of dependencies.
check_bugs() in init/main.c calls identify_cpu() (the
real CPU ident workhorse) much too late.  Now call
identify_cpu(for the boot cpu) from trap_init().
Still call identify_cpu(for other cpus) from smp_store_cpu_info(),
but add a call here to (new) finish_cpu_setup(&cpu_data)
for setup code that can be done later rather than earlier.
Note:  identify_cpu() wants to know loops_per_jiffy,
so if it is 0, call calibrate_delay() to get it.

Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
---
 arch/i386/kernel/cpu/common.c |   11 +++++++++++
 arch/i386/kernel/smpboot.c    |    4 +++-
 arch/i386/kernel/traps.c      |    2 ++
 include/asm-i386/bugs.h       |    1 -
 include/linux/smp.h           |    6 ++++++
 init/main.c                   |    2 ++
 6 files changed, 24 insertions(+), 2 deletions(-)

--- linux-2618-g18.orig/arch/i386/kernel/cpu/common.c
+++ linux-2618-g18/arch/i386/kernel/cpu/common.c
@@ -355,6 +355,8 @@ void __cpuinit identify_cpu(struct cpuin
 {
 	int i;
 
+	if (!loops_per_jiffy)
+		calibrate_delay();
 	c->loops_per_jiffy = loops_per_jiffy;
 	c->x86_cache_size = -1;
 	c->x86_vendor = X86_VENDOR_UNKNOWN;
@@ -461,7 +463,11 @@ void __cpuinit identify_cpu(struct cpuin
 
 	/* Init Machine Check Exception if available. */
 	mcheck_init(c);
+}
 
+/* after kmem_cache_init => kmalloc works */
+void __cpuinit finish_cpu_setup(struct cpuinfo_x86 *c)
+{
 	if (c == &boot_cpu_data)
 		sysenter_setup();
 	enable_sep_cpu();
@@ -472,6 +478,11 @@ void __cpuinit identify_cpu(struct cpuin
 		mtrr_ap_init();
 }
 
+void __cpuinit finish_boot_cpu_setup(void)
+{
+	finish_cpu_setup(&boot_cpu_data);
+}
+
 #ifdef CONFIG_X86_HT
 void __cpuinit detect_ht(struct cpuinfo_x86 *c)
 {
--- linux-2618-g18.orig/arch/i386/kernel/traps.c
+++ linux-2618-g18/arch/i386/kernel/traps.c
@@ -1249,6 +1249,8 @@ void __init trap_init(void)
 #endif
 	set_trap_gate(19,&simd_coprocessor_error);
 
+	identify_cpu(&boot_cpu_data);
+
 	if (cpu_has_fxsr) {
 		/*
 		 * Verify that the FXSAVE/FXRSTOR data will be 16-byte aligned.
--- linux-2618-g18.orig/include/asm-i386/bugs.h
+++ linux-2618-g18/include/asm-i386/bugs.h
@@ -180,7 +180,6 @@ extern void alternative_instructions(voi
 
 static void __init check_bugs(void)
 {
-	identify_cpu(&boot_cpu_data);
 #ifndef CONFIG_SMP
 	printk("CPU: ");
 	print_cpu_info(&boot_cpu_data);
--- linux-2618-g18.orig/arch/i386/kernel/smpboot.c
+++ linux-2618-g18/arch/i386/kernel/smpboot.c
@@ -159,8 +159,10 @@ static void __devinit smp_store_cpu_info
 	struct cpuinfo_x86 *c = cpu_data + id;
 
 	*c = boot_cpu_data;
-	if (id!=0)
+	if (id != 0) {
 		identify_cpu(c);
+		finish_cpu_setup(c);
+	}
 	/*
 	 * Mask B, Pentium, but not Pentium MMX
 	 */
--- linux-2618-g18.orig/include/linux/smp.h
+++ linux-2618-g18/include/linux/smp.h
@@ -130,4 +130,10 @@ static inline void smp_send_reschedule(i
 
 void smp_setup_processor_id(void);
 
+/*
+ * finish the boot CPU setup:
+ * allows kmalloc etc., which is not possible during identify_cpu().
+ */
+void finish_boot_cpu_setup(void);
+
 #endif /* __LINUX_SMP_H */
--- linux-2618-g18.orig/init/main.c
+++ linux-2618-g18/init/main.c
@@ -49,6 +49,7 @@
 #include <linux/buffer_head.h>
 #include <linux/debug_locks.h>
 #include <linux/lockdep.h>
+#include <linux/smp.h>
 
 #include <asm/io.h>
 #include <asm/bugs.h>
@@ -570,6 +571,7 @@ asmlinkage void __init start_kernel(void
 	cpuset_init_early();
 	mem_init();
 	kmem_cache_init();
+	finish_boot_cpu_setup();
 	setup_per_cpu_pageset();
 	numa_policy_init();
 	if (late_time_init)

Re: [PATCH/RFC] Math-emu kills the kernel on Athlon64 X2

[Linus Torvalds]

On Mon, 2 Oct 2006, Randy Dunlap wrote:
> 
> I had no trouble reproducing the boot failure (on Pentium-M), then
> I tried TRACE_RESUME().  Nifty, but not really needed here since
> earlyprintk worked and contained the fault messages:
> 
> [   16.841784] math_emulate: 0060:c01062dd
> [   16.845579] Kernel panic - not syncing: Math emulation needed in kernel
> 
> But CONFIG_MATH_EMULATION=y, so what now?

The "Math emulation needed in kernel" message means that it was asked to 
emulate a kernel instruction, and it refuses to do so. The emulation is 
_not_ meant to be a real FPU, it simply looks like one to user space. A 
lot of things aren't really emulated (there's no global x87 context, for 
example: the context is all strictly per-process).

> Linus mentioned CPU feature bits.  The message log above didn't
> make me feel good about them.  Sure enough, we are playing with
> features before reading the feature bits.

Please look up address c01062dd in the system map (or just using gdb), 
that will tell you what code _tried_ to use the math coprocessor in kernel 
space.

			Linus

Re: [PATCH/RFC] Math-emu kills the kernel on Athlon64 X2

[Randy Dunlap]

On Mon, 2 Oct 2006 19:34:27 -0700 (PDT) Linus Torvalds wrote:

> 
> 
> On Mon, 2 Oct 2006, Randy Dunlap wrote:
> > 
> > I had no trouble reproducing the boot failure (on Pentium-M), then
> > I tried TRACE_RESUME().  Nifty, but not really needed here since
> > earlyprintk worked and contained the fault messages:
> > 
> > [   16.841784] math_emulate: 0060:c01062dd
> > [   16.845579] Kernel panic - not syncing: Math emulation needed in kernel
> > 
> > But CONFIG_MATH_EMULATION=y, so what now?
> 
> The "Math emulation needed in kernel" message means that it was asked to 
> emulate a kernel instruction, and it refuses to do so. The emulation is 
> _not_ meant to be a real FPU, it simply looks like one to user space. A 
> lot of things aren't really emulated (there's no global x87 context, for 
> example: the context is all strictly per-process).
> 
> > Linus mentioned CPU feature bits.  The message log above didn't
> > make me feel good about them.  Sure enough, we are playing with
> > features before reading the feature bits.
> 
> Please look up address c01062dd in the system map (or just using gdb), 
> that will tell you what code _tried_ to use the math coprocessor in kernel 
> space.

Sure, it's in arch/i386/kernel/i387.c::mxcsr_feature_mask_init(),
on the fxsave instruction:

void mxcsr_feature_mask_init(void)
{
	unsigned long mask = 0;
	clts();
	if (cpu_has_fxsr) {
		memset(&current->thread.i387.fxsave, 0, sizeof(struct i387_fxsave_struct));
		asm volatile("fxsave %0" : : "m" (current->thread.i387.fxsave)); 
		mask = current->thread.i387.fxsave.mxcsr_mask;
		if (mask == 0) mask = 0x0000ffbf;
	}

---
~Randy

Re: [PATCH/RFC] Math-emu kills the kernel on Athlon64 X2

[Andi Kleen]

 
> void mxcsr_feature_mask_init(void)
> {
> 	unsigned long mask = 0;
> 	clts();
> 	if (cpu_has_fxsr) {
> 		memset(&current->thread.i387.fxsave, 0, sizeof(struct i387_fxsave_struct));
> 		asm volatile("fxsave %0" : : "m" (current->thread.i387.fxsave)); 
> 		mask = current->thread.i387.fxsave.mxcsr_mask;
> 		if (mask == 0) mask = 0x0000ffbf;
> 	}

This just needs an ifdef. I'll fix that thanks.

-Andi

Re: [PATCH/RFC] Math-emu kills the kernel on Athlon64 X2

[Linus Torvalds]

On Tue, 3 Oct 2006, Andi Kleen wrote:

>  
> > void mxcsr_feature_mask_init(void)
> > {
> > 	unsigned long mask = 0;
> > 	clts();
> > 	if (cpu_has_fxsr) {
> > 		memset(&current->thread.i387.fxsave, 0, sizeof(struct i387_fxsave_struct));
> > 		asm volatile("fxsave %0" : : "m" (current->thread.i387.fxsave)); 
> > 		mask = current->thread.i387.fxsave.mxcsr_mask;
> > 		if (mask == 0) mask = 0x0000ffbf;
> > 	}
> 
> This just needs an ifdef. I'll fix that thanks.

No, it doesn't need "an ifdef" at all.

There is no #define to even _test_. The fact that FPU math emulation is 
compiled in in _no_ way means that it should statically be used. It just 
means that if the user asks the math coprocessor to not be used, or if no 
such coprocessor exists, we shouldn't do an "fxsave".

The real fix is to clear "fxsr" when the user said "no387". If you don't 
have a math coprocessor, you sure as heck don't have fxsr either.

However, that's apparently not enough, since "nofxsr" was reported to not 
fix it entirely. However, that might well be true due to just handling 
that flag too late, or something.

And THAT is the real bug. Don't try to make it anything else. The bug is 
simply that we use the math coprocessor when we've been told it doesn't 
exist. 

			Linus

Re: [PATCH/RFC] Math-emu kills the kernel on Athlon64 X2 II -- it's terminally broken

[Andi Kleen]

On Tuesday 03 October 2006 05:24, Randy Dunlap wrote:

Actually I looked at the code more closely. It looks like kernel math
emulation is much more broken. e.g. kernel_fpu_begin() is missing
code and lots of other paths in i387 that need to check HAVE_HWFP don't.

Fixing it properly would be much more work.

Since it evidently hasn't worked for a long time I'm thinkin about
just marking it CONFIG_BROKEN and deprecating it for 2.6.20

Comments? 

-Andi

Re: [PATCH/RFC] Math-emu kills the kernel on Athlon64 X2 II -- it's terminally broken

[Alan Cox]

Ar Maw, 2006-10-03 am 12:11 +0200, ysgrifennodd Andi Kleen:
> On Tuesday 03 October 2006 05:24, Randy Dunlap wrote:
> 
> Actually I looked at the code more closely. It looks like kernel math
> emulation is much more broken. e.g. kernel_fpu_begin() is missing
> code and lots of other paths in i387 that need to check HAVE_HWFP don't.

That check would be wrong anyway. A kernel built with FPU emulation
boots, runs and uses the hardware FPU code correctly. The problem area
is the X86_FEATURE_foo stuff. I think that comes down to a single thing
- if we have FPU disabled clear X86_FEATURE_FXSR|X86_FEATURE_MMX|
X86_FEATURE_SSE* in the boot cpu features during early option
parsing/setup. Basically the emulated FPU is forgetting to tell the
truth about the fact its a very basic FPU.

Alan

Re: [PATCH/RFC] Math-emu kills the kernel on Athlon64 X2 II -- it's terminally broken

[Linus Torvalds]

On Tue, 3 Oct 2006, Andi Kleen wrote:
> 
> Actually I looked at the code more closely. It looks like kernel math
> emulation is much more broken. e.g. kernel_fpu_begin() is missing
> code and lots of other paths in i387 that need to check HAVE_HWFP don't.

No it's not.

kernel_fpu_begin() has the _one_ test that matters:

	if (thread->status & TS_USEDFPU) {

since if software emulation is on, nobody will ever have the TS_USEDFPU 
flag set.

> Fixing it properly would be much more work.

No. It's all fixed properly already.

The bug is simply on the newer FXSR paths - marking the FPU emulation 
broken is just stupid. 

		Linus

Re: [PATCH/RFC] Math-emu kills the kernel on Athlon64 X2

[Randy Dunlap]

OK, how about something more direct and less obtrusive, like this?

---
From: Randy Dunlap <rdunlap@xenotime.net>

Honor "nofxsr" boot option during init.
Eliminates the math fault during boot.

Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
---
 arch/i386/kernel/cpu/common.c |    2 +-
 arch/i386/kernel/i387.c       |    2 +-
 include/asm-i386/i387.h       |    2 ++
 3 files changed, 4 insertions(+), 2 deletions(-)

--- linux-2618-g18.orig/arch/i386/kernel/cpu/common.c
+++ linux-2618-g18/arch/i386/kernel/cpu/common.c
@@ -28,7 +28,7 @@ DEFINE_PER_CPU(unsigned char, cpu_16bit_
 EXPORT_PER_CPU_SYMBOL(cpu_16bit_stack);
 
 static int cachesize_override __cpuinitdata = -1;
-static int disable_x86_fxsr __cpuinitdata;
+int disable_x86_fxsr __cpuinitdata;
 static int disable_x86_serial_nr __cpuinitdata = 1;
 static int disable_x86_sep __cpuinitdata;
 
--- linux-2618-g18.orig/arch/i386/kernel/i387.c
+++ linux-2618-g18/arch/i386/kernel/i387.c
@@ -30,7 +30,7 @@ void mxcsr_feature_mask_init(void)
 {
 	unsigned long mask = 0;
 	clts();
-	if (cpu_has_fxsr) {
+	if (cpu_has_fxsr && !disable_x86_fxsr) {
 		memset(&current->thread.i387.fxsave, 0, sizeof(struct i387_fxsave_struct));
 		asm volatile("fxsave %0" : : "m" (current->thread.i387.fxsave)); 
 		mask = current->thread.i387.fxsave.mxcsr_mask;
--- linux-2618-g18.orig/include/asm-i386/i387.h
+++ linux-2618-g18/include/asm-i386/i387.h
@@ -18,6 +18,8 @@
 #include <asm/sigcontext.h>
 #include <asm/user.h>
 
+extern int disable_x86_fxsr;
+
 extern void mxcsr_feature_mask_init(void);
 extern void init_fpu(struct task_struct *);
 

Re: [PATCH/RFC] Math-emu kills the kernel on Athlon64 X2

[Alan Cox]

Ar Llu, 2006-10-02 am 21:38 -0700, ysgrifennodd Randy Dunlap:
> OK, how about something more direct and less obtrusive, like this?
> 
> ---
> From: Randy Dunlap <rdunlap@xenotime.net>
> 
> Honor "nofxsr" boot option during init.
> Eliminates the math fault during boot.

Why not just check the flags we set early on to indicate we have a real
FPU instead of another boot option ?

Re: [PATCH/RFC] Math-emu kills the kernel on Athlon64 X2

[Linus Torvalds]

On Mon, 2 Oct 2006, Randy Dunlap wrote:
> 
> OK, how about something more direct and less obtrusive, like this?

I think this is fine, but I also think it's a bit hacky.

Wouldn't it make more sense to make the whole "nofxsr" thing just clear 
the capability, ie just a diff like the appended...

Does that work for you? If so, we should _also_ make sure that "no387" 
calls this function too, so that you don't have to do _both_ no387 and 
nofxsr, which is clearly silly. Once you do no387, the kernel should do 
the nofxsr for you, methinks..

		Linus

---
diff --git a/arch/i386/kernel/cpu/common.c b/arch/i386/kernel/cpu/common.c
index 2799baa..7ac3c9e 100644
--- a/arch/i386/kernel/cpu/common.c
+++ b/arch/i386/kernel/cpu/common.c
@@ -185,6 +185,7 @@ static void __cpuinit get_cpu_vendor(str
 static int __init x86_fxsr_setup(char * s)
 {
 	disable_x86_fxsr = 1;
+	clear_bit(X86_FEATURE_FXSR, boot_cpu_data.x86_capability);
 	return 1;
 }
 __setup("nofxsr", x86_fxsr_setup);

Re: [PATCH/RFC] Math-emu kills the kernel on Athlon64 X2

[Randy Dunlap]

On Tue, 3 Oct 2006 08:10:07 -0700 (PDT) Linus Torvalds wrote:

> 
> 
> On Mon, 2 Oct 2006, Randy Dunlap wrote:
> > 
> > OK, how about something more direct and less obtrusive, like this?
> 
> I think this is fine, but I also think it's a bit hacky.
> 
> Wouldn't it make more sense to make the whole "nofxsr" thing just clear 
> the capability, ie just a diff like the appended...
> 
> Does that work for you? If so, we should _also_ make sure that "no387" 
> calls this function too, so that you don't have to do _both_ no387 and 
> nofxsr, which is clearly silly. Once you do no387, the kernel should do 
> the nofxsr for you, methinks..

Yes, that works.

> ---
> diff --git a/arch/i386/kernel/cpu/common.c b/arch/i386/kernel/cpu/common.c
> index 2799baa..7ac3c9e 100644
> --- a/arch/i386/kernel/cpu/common.c
> +++ b/arch/i386/kernel/cpu/common.c
> @@ -185,6 +185,7 @@ static void __cpuinit get_cpu_vendor(str
>  static int __init x86_fxsr_setup(char * s)
>  {
>  	disable_x86_fxsr = 1;
> +	clear_bit(X86_FEATURE_FXSR, boot_cpu_data.x86_capability);
>  	return 1;
>  }
>  __setup("nofxsr", x86_fxsr_setup);

---
~Randy

Re: [PATCH/RFC] Math-emu kills the kernel on Athlon64 X2

[Linus Torvalds]

On Tue, 3 Oct 2006, Randy Dunlap wrote:
> 
> Yes, that works.

Ok. I'll commit that simple thing, and add a comment on why we're 
apparently doing the same thing twice (you do need _both_ of those things: 
the "disable_x86_fxsr" will make sure all other CPU's also get cleared, 
while the "clear_bit()" will clear it immediately on the boot CPU)

I'll leave the no387/nofxsr linking alone for now. The main reason to use 
no387 would seem to be just testing that emulation works at all, and I 
guess we can just tell people to use the "no387 nofxsr" combination.

So Randy, with this you can boot all the way into user space, and some FP 
apps still work too?

(Of course, user-space may be buggy and use SSE etc without testing for 
whether the CPU actually supports it - if the install process has 
installed some special SSE-version of a library depending on what the CPU 
claimed at that point, or if somebody uses "cpuid" directly rather than 
asking the kernel. So there's no way we're going to _guarantee_ that this 
works in user space, but at least a well-behaved user-space that works on 
a i486 should hopefully be ok).

			Linus

Re: [PATCH/RFC] Math-emu kills the kernel on Athlon64 X2

[Randy Dunlap]

On Tue, 3 Oct 2006 09:37:45 -0700 (PDT) Linus Torvalds wrote:

> 
> 
> On Tue, 3 Oct 2006, Randy Dunlap wrote:
> > 
> > Yes, that works.
> 
> Ok. I'll commit that simple thing, and add a comment on why we're 
> apparently doing the same thing twice (you do need _both_ of those things: 
> the "disable_x86_fxsr" will make sure all other CPU's also get cleared, 
> while the "clear_bit()" will clear it immediately on the boot CPU)
> 
> I'll leave the no387/nofxsr linking alone for now. The main reason to use 
> no387 would seem to be just testing that emulation works at all, and I 
> guess we can just tell people to use the "no387 nofxsr" combination.
> 
> So Randy, with this you can boot all the way into user space, and some FP 
> apps still work too?

My few trivial float and double apps work.
Is there any particular test/workload that you want me to run?

> (Of course, user-space may be buggy and use SSE etc without testing for 
> whether the CPU actually supports it - if the install process has 
> installed some special SSE-version of a library depending on what the CPU 
> claimed at that point, or if somebody uses "cpuid" directly rather than 
> asking the kernel. So there's no way we're going to _guarantee_ that this 
> works in user space, but at least a well-behaved user-space that works on 
> a i486 should hopefully be ok).


---
~Randy

Re: [PATCH/RFC] Math-emu kills the kernel on Athlon64 X2

[Linus Torvalds]

On Tue, 3 Oct 2006, Randy Dunlap wrote:
> > 
> > So Randy, with this you can boot all the way into user space, and some FP 
> > apps still work too?
> 
> My few trivial float and double apps work.
> Is there any particular test/workload that you want me to run?

Not really, if "most things just seem to work", that's already pretty much 
all we should ask for from the math emulation.

		Linus

Re: [PATCH/RFC] Math-emu kills the kernel on Athlon64 X2

[Jesper Juhl]

On 03/10/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Tue, 3 Oct 2006, Randy Dunlap wrote:
> > >
> > > So Randy, with this you can boot all the way into user space, and some FP
> > > apps still work too?
> >
> > My few trivial float and double apps work.
> > Is there any particular test/workload that you want me to run?
>
> Not really, if "most things just seem to work", that's already pretty much
> all we should ask for from the math emulation.
>

I just tested 2.6.18-git21 and here's a small status report :

The good news is: The kernel boots.
The bad news is: Userspace breaks left and right.

I'm booting with "no387 nofxsr"

On my first boot I just used the options above and the result was that
most of the bootup sequence looked quite normal until I got to the
point of starting sshd, then things started to go wrong. This is what
I got :

...
/etc/rc.d/rc.sshd: line 4: 1491 Illegal instruction    /usr/sbin/sshd
...
/usr/sbin/apachectl: line 81:    1588 Illegal instruction    $HTTPD
/usr/sbin/apachectl: start: httpd could not be started
Starting up X11 Session manager...
   At this point X starts and gets as far as showing me the default X
cursor on a black background very briefly, then I'm back in text mode
and the box is hung - CTRL+ALT+DEL did work, but that was about it.

Then I tried a boot to single user mode ("no387 nofxsr single").
That worked a little better, although sshd and abache were still
broken (didn't really expect otherwise). I managed to get a login
prompt, logged in and successfully switched to runlevel 3 (which on my
distro (Slackware 11) is multi-user without X). Then I tried to
"startx" by hand to see if that would get me any further details, and
it did. I got this :

...
(==) Using config file: "/etc/X11/xorg.conf"
Could not init font path element /usr/X11R6/lib/X11/fonts/CID/, removing
from list!
xset:  bad font path element (#62), possible causes are:
    Directory does not exist or has wrong permissions
    Directory missing fonts.dir
    Incorrect font server address or syntax
xset:  bad font path element (#62), possible causes are:
    Directory does not exist or has wrong permissions
    Directory missing fonts.dir
    Incorrect font server address or syntax

   *** If unresolved symbols were reported above, they might not
   *** be the reason for the server aborting.

Backtrace:
0: X(xf86SigHandler+0x8a) [0x8088b2a]
1: [0xb7fb9420]
2: /usr/X11R6/lib/modules/libfb.so(fbCopyNtoN+0x214) [0xb79658d4]
3: /usr/X11R6/lib/modules/libfb.so(fbCopyRegion+0x1df) [0xb796617f]
4: /usr/X11R6/lib/modules/libfb.so(fbDoCopy+0x46b) [0xb796660b]
5: /usr/X11R6/lib/modules/libfb.so(fbCopyArea+0x78) [0xb79666b8]
6: /usr/X11R6/lib/modules/libshadow.so [0xb7985c34]
7: X [0x8168ec1]
8: X [0x81b2260]
9: X [0x81b06cc]
10: X [0x81b12b8]
11: X(miPointerUpdate+0x126) [0x81afbc6]
12: X [0x81afc7b]
13: X [0x816e262]
14: X [0x8183a4e]
15: X [0x80c9c95]
16: X(ChangeWindowAttributes+0x9ee) [0x80dceee]
17: X(ProcChangeWindowAttributes+0x81) [0x80c0e21]
18: X(Dispatch+0x171) [0x80c7e21]
19: X(main+0x3ed) [0x80d465d]
20: /lib/tls/libc.so.6(__libc_start_main+0xd4) [0xb7e39e14]
21: X [0x806ff61]

Fatal server error:
Caught signal 4.  Server aborting


Please consult the The X.Org Foundation support
         at http://wiki.X.Org
 for help.
Please also check the log file at "/var/log/Xorg.0.log" for additional
information.

X connection to :0.0 broken (explicit kill or server shutdown).
/usr/X11R6/bin/xinit:  connection to X server lost.
root@(none):~# GOT SIGHUP
startkde: Starting up...
ksplash: cannot connect to X server :0
kdeinit: Can't connect to the X Server.
kdeinit: Might not terminate at end of session.
kded: cannot connect to X server :0
DCOP aborting call from 'anonymous-2278' to 'kded'
kded: ERROR: Communication problem with kded, it probably crashed.
kcminit_startup: cannot connect to X server :0
root@(none):~#
ksmserver: cannot connect to X server :0
startkde: Shutting down...
klauncher: Exiting on signal 1
startkde: Running shutdown scripts...
startkde: Done.
root@(none):~#

This time the system didn't hang, it was still somewhat usable (except
for random apps breaking with "Illegal instruction").


So that's great progress, but it could certainly work a lot better.


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: [PATCH/RFC] Math-emu kills the kernel on Athlon64 X2

[Linus Torvalds]

On Wed, 4 Oct 2006, Jesper Juhl wrote:
> 
> I just tested 2.6.18-git21 and here's a small status report :
> 
> The good news is: The kernel boots.
> The bad news is: Userspace breaks left and right.
> 
> I'm booting with "no387 nofxsr"
> 
> On my first boot I just used the options above and the result was that
> most of the bootup sequence looked quite normal until I got to the
> point of starting sshd, then things started to go wrong. This is what
> I got :
> 
> ...
> /etc/rc.d/rc.sshd: line 4: 1491 Illegal instruction    /usr/sbin/sshd

Ok, I bet you have your sshd compiled to use MMX instructions 
unconditionally.

> So that's great progress, but it could certainly work a lot better.

I don't think there is a whole lot we can do about it. There's really two 
choices:

 - make sure all user-space is able to function without MMX. This means, 
   for example, that you must certainly never compile with some code that 
   switches between MMX and non-MMX statically.

   The most common cases you'd expect to use MMX is for encryption, but 
   graphics and 3D certainly sounds very possible too..

   This isn't really somethign _we_ can do a lot about, although 
   distributions that care may of course try to test that their distro 
   works with "no387 nofxsr". You didn't say what distro you used, maybe 
   you can point it out to them.

 - we could try to extend the math emulator to emulate the new 
   instructions too.

   The thing is, it's probably not worth it. The only actual real usage 
   would be if somebody wants to take a disk image and switch to a really 
   old machine that lacked the MMX instruction, or for this particular 
   test-case.

so I suspect that in practice, the answer is "if the distro isn't compiled 
for a generic x86 target, screw it".

			Linus

Re: [PATCH/RFC] Math-emu kills the kernel on Athlon64 X2

[Jesper Juhl]

On 04/10/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
> On Wed, 4 Oct 2006, Jesper Juhl wrote:
> >
> > I just tested 2.6.18-git21 and here's a small status report :
> >
> > The good news is: The kernel boots.
> > The bad news is: Userspace breaks left and right.
> >
> > I'm booting with "no387 nofxsr"
> >
> > On my first boot I just used the options above and the result was that
> > most of the bootup sequence looked quite normal until I got to the
> > point of starting sshd, then things started to go wrong. This is what
> > I got :
> >
> > ...
> > /etc/rc.d/rc.sshd: line 4: 1491 Illegal instruction    /usr/sbin/sshd
>
> Ok, I bet you have your sshd compiled to use MMX instructions
> unconditionally.
>

Probably, I haven't checked.


> > So that's great progress, but it could certainly work a lot better.
>
> I don't think there is a whole lot we can do about it. There's really two
> choices:
>
>  - make sure all user-space is able to function without MMX. This means,
>    for example, that you must certainly never compile with some code that
>    switches between MMX and non-MMX statically.
>
If the emulator can't handle it (which it cannot), that makes perfect sense :)

>    The most common cases you'd expect to use MMX is for encryption, but
>    graphics and 3D certainly sounds very possible too..
>
>    This isn't really somethign _we_ can do a lot about, although
>    distributions that care may of course try to test that their distro
>    works with "no387 nofxsr". You didn't say what distro you used, maybe
>    you can point it out to them.
>

Actually, I did (Slackware 11) :

   > broken (didn't really expect otherwise). I managed to get a login
   > prompt, logged in and successfully switched to runlevel 3 (which on my
   > distro (Slackware 11) is multi-user without X). Then I tried to


>  - we could try to extend the math emulator to emulate the new
>    instructions too.
>
That would, in my oppinion, be the right way forward.

I fondly remember the days of old when I had an old 386 with no 387
and I was able to move my kernel between my machine and my friends
486SX/DX & Pentium boxes and with the math emulator in place
*everything* just worked perfectly - it may have been a little slow
with the emulator, but it always worked correctly, even though the
disk I moved around was setup to always use the emulator... I would
love to get that back.


>    The thing is, it's probably not worth it. The only actual real usage
>    would be if somebody wants to take a disk image and switch to a really
>    old machine that lacked the MMX instruction, or for this particular
>    test-case.
>
I think I can think of a few more.

One is obviously, as you say, move a disk image (or live CD) to a
really old machine.
Another is just to test the math emulator (this test case).
Another is platforms that don't have a math co-processor or
MMX/SSE/3DNow etc at all, their life would be simplified if the
emulator "just worked".
Another example (a bit far fetched, I admit) would be a damaged CPU
where the FPU doesn't work.
Yet another case would be where someone wanted to use the emulator for
better precision than the hardware gives and the slowdown is
acceptable - I may be imagining this, but I seem to have this memory
telling me that for some things back in the days the emulator was
actually more precise than the hardware.


> so I suspect that in practice, the answer is "if the distro isn't compiled
> for a generic x86 target, screw it".
>
I guess I'll have to accept that or start hacking on the emulator
myself :)   Let's see...


There is one thing we can easily do though, to improve things.
I noticed when booting my Athlon 64 X2 4400+ with "no387 nofxsr" that
the "flags" line in /proc/cpuinfo still report stuff that's not
supported by the emulator :

...
flags           : fpu vme de tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush mmx sse2 ht syscall nx mmxext fxsr_opt lm
3dnowext 3dnow pni lahf_lm cmp_legacy ts fid vid ttp
...

When the emulator is in effect, shouldn't we remove things like "mmx,
sse2, mmxext, fxsr_opt, 3dnowext, 3dnow, pni" from the /proc/cpuinfo
output?
That would prevent silly apps that check the flags line from
/proc/cpuinfo for CPU capabilities from detecting a capability that we
are not able to support.    Yes, I know that an app that relies on
/proc/cpuinfo for detection of this is silly/stupid, but the last
stupid programmer has not been born yet, and such apps may very well
exist in the wild. Not printing stuff we can't emulate will probably
make a few apps out there behave correctly with math-emu in effect,
and I don't see any downside...   I can try to prepare a patch if you
like...?


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: [PATCH/RFC] Math-emu kills the kernel on Athlon64 X2

[Alan Cox]

Ar Mer, 2006-10-04 am 22:02 +0200, ysgrifennodd Jesper Juhl:
> > > /etc/rc.d/rc.sshd: line 4: 1491 Illegal instruction    /usr/sbin/sshd
> >
> > Ok, I bet you have your sshd compiled to use MMX instructions
> > unconditionally.
> >
> Probably, I haven't checked.

Or we aren't correctly masking all the other cpuid bits we should in
this case..

Re: [PATCH/RFC] Math-emu kills the kernel on Athlon64 X2

[Andi Kleen]

On Thursday 05 October 2006 00:00, Alan Cox wrote:
> Ar Mer, 2006-10-04 am 22:02 +0200, ysgrifennodd Jesper Juhl:
> > > > /etc/rc.d/rc.sshd: line 4: 1491 Illegal instruction    /usr/sbin/sshd
> > >
> > > Ok, I bet you have your sshd compiled to use MMX instructions
> > > unconditionally.
> > >
> > Probably, I haven't checked.
> 
> Or we aren't correctly masking all the other cpuid bits we should in
> this case..

It might be using CPUID directly which can't be masked

-Andi

Re: Math-emu kills the kernel on Athlon64 X2

[Andi Kleen]

On Tuesday 19 September 2006 23:14, Jesper Juhl wrote:
> On 19 Sep 2006 10:01:55 +0200, Andi Kleen <ak@suse.de> wrote:
> > "Jesper Juhl" <jesper.juhl@gmail.com> writes:
> >
> > > Hi,
> > >
> > > If I enable the math emulator in 2.6.18-rc7-git2 (only version I've
> > > tried this with) and then boot the kernel with "no387" then I only get
> > > as far as lilo's "...Booting the kernel." message and then the system
> > > hangs.
> > >
> > > The kernel is a 32bit kernel build for K8 and my CPU is a Athlon64 X2 4400+
> >
> > Do you have a .config? I tried it and it booted until mounting root.
> >
> 
> The config is attached.

Still can't reproduce it unfortunately. I ran it on a fairly accurate 
Simulator and it seems to get until mounting root. It might depend 
on the compiler version though. I was using gcc 4.1.

-Andi

Re: Math-emu kills the kernel on Athlon64 X2

[linux]

> Fine :),  My (12 year old) 486DX2 already don't need Math-emu. I just
> don't see how in a computer like that will be installed a kernel 2.6 .
> So why code of math-emu isn't dropped ? 

Google for "386EX".  There are any number of embedded boards
based on an this FPU-less 386 which people like to run Linux on.

There's more to the world than personal computers; the fact that the
Linux kernel runs almost unmodified on most of the largest computers in
the world (http://www.top500.org/stats/27/os/) and some of the dinkiest
(http://www.research.ibm.com/WearableComputing/linuxwatch/linuxwatch.html)
is a source of considerable pride.