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 <[email protected]>
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
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
On 19/09/06, Linus Torvalds <[email protected]> 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 <[email protected]>
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
On Tue, 19 Sep 2006, Jesper Juhl wrote:
> On 19/09/06, Linus Torvalds <[email protected]> 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(¤t->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
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.
On 19/09/06, Sergio Monteiro Basto <[email protected]> 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 <[email protected]>
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
On 19/09/06, Linus Torvalds <[email protected]> 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 <[email protected]>
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
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
"Jesper Juhl" <[email protected]> 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
On 19 Sep 2006 10:01:55 +0200, Andi Kleen <[email protected]> wrote:
> "Jesper Juhl" <[email protected]> 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 <[email protected]>
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
Sergio Monteiro Basto <[email protected]> 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
On 19 Sep 2006 10:01:55 +0200, Andi Kleen <[email protected]> wrote:
> "Jesper Juhl" <[email protected]> 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 <[email protected]>
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
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.
On 20/09/06, Linus Torvalds <[email protected]> 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 <[email protected]>
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
On 20/09/06, Jesper Juhl <[email protected]> wrote:
> On 20/09/06, Linus Torvalds <[email protected]> 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 <[email protected]>
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
On Tue, 2006-09-19 at 14:28 +0200, Krzysztof Halasa wrote:
> Sergio Monteiro Basto <[email protected]> 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.
> 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.
On Tuesday 19 September 2006 23:14, Jesper Juhl wrote:
> On 19 Sep 2006 10:01:55 +0200, Andi Kleen <[email protected]> wrote:
> > "Jesper Juhl" <[email protected]> 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
Sergio Monteiro Basto <[email protected]> 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
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 [email protected]/eth0,[email protected]/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 <[email protected]>
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 <[email protected]>
---
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)
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
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(¤t->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
OK, how about something more direct and less obtrusive, like this?
---
From: Randy Dunlap <[email protected]>
Honor "nofxsr" boot option during init.
Eliminates the math fault during boot.
Signed-off-by: Randy Dunlap <[email protected]>
---
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(¤t->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 *);
> void mxcsr_feature_mask_init(void)
> {
> unsigned long mask = 0;
> clts();
> if (cpu_has_fxsr) {
> memset(¤t->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
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
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 <[email protected]>
>
> 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 ?
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
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
On Tue, 3 Oct 2006, Andi Kleen wrote:
>
> > void mxcsr_feature_mask_init(void)
> > {
> > unsigned long mask = 0;
> > clts();
> > if (cpu_has_fxsr) {
> > memset(¤t->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
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);
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
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
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
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
On 03/10/06, Linus Torvalds <[email protected]> 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 <[email protected]>
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
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
On 04/10/06, Linus Torvalds <[email protected]> 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 <[email protected]>
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
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..
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