Bug 298811
|
Description
William Reich
2007-09-20 18:33:20 UTC
William, are you seeing a driver load failure or a driver operation failure? In either case, could you please attach: a) /proc/cpuinfo, /proc/meminfo, b) lspci -xxx -vv c) a log of the failure Thanks, P. William, I was just speaking with my colleague jbaron (cc'd on this BZ) who mentioned that there have been some allocation related patches in this area of code. Could you please grab the 59.EL5 (or newer) kernel from http://people.redhat.com/~jbaron/rhel4/ and retest? Thanks, P. what is this ? " 59.EL5 (or newer) kernel from http://people.redhat.com/~jbaron/rhel4/ and retest? " Is this an update to Red Hat 4 or is this a version of Red Hat 5 ? When we did an "up to date" on 9/19, we receive a 2.6.55 kernel for RH 4. I will retrieve the log items you requested in comment #2. Please note that item (c) in this list is from my code. If is a simple " if " statement - if the address received is not a multiple of 64k, then complain... I would classify the error as a "driver operation error" because the error occurs in the initialization logic of the driver. Here is the data you asked for.
Also included is the /boot/grub/grub.conf file.
This is the RH 4 Update 4 64bit box.
+++++++++++++++++++++++++++++
00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a4)
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: <available only to root>
00: de 10 5e 00 06 01 b0 00 a4 00 80 05 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 44 00 00 00 00 00 00 00 00 00 00 00
00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev b1)
Subsystem: nVidia Corporation: Unknown device cb84
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
00: de 10 51 00 0f 00 a0 00 b1 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 de 10 84 cb
30: 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 00 00
00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
(prog-if 10 [OHCI])
Subsystem: Hewlett-Packard Company: Unknown device 31f8
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 (750ns min, 250ns max)
Interrupt: pin A routed to IRQ 177
Region 0: Memory at f39e0000 (32-bit, non-prefetchable) [size=4K]
Capabilities: <available only to root>
00: de 10 5a 00 07 00 b0 00 a2 10 03 0c 00 00 80 00
10: 00 00 9e f3 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 3c 10 f8 31
30: 00 00 00 00 44 00 00 00 00 00 00 00 05 01 03 01
00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a4)
(prog-if 20 [EHCI])
Subsystem: Hewlett-Packard Company: Unknown device 31f8
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 (750ns min, 250ns max)
Interrupt: pin B routed to IRQ 185
Region 0: Memory at f39d0000 (32-bit, non-prefetchable) [size=256]
Capabilities: <available only to root>
00: de 10 5b 00 06 00 b0 00 a4 20 03 0c 00 00 80 00
10: 00 00 9d f3 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 3c 10 f8 31
30: 00 00 00 00 44 00 00 00 00 00 00 00 0a 02 03 01
00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev a3) (prog-if 8a [Master
SecP PriP])
Subsystem: Hewlett-Packard Company: Unknown device 31f8
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 (750ns min, 250ns max)
Region 4: I/O ports at 1000 [size=16]
Capabilities: <available only to root>
00: de 10 53 00 05 00 b0 00 a3 8a 01 01 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 10 00 00 00 00 00 00 00 00 00 00 3c 10 f8 31
30: 00 00 00 00 44 00 00 00 00 00 00 00 00 00 03 01
00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2) (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=01, subordinate=01, sec-latency=120
I/O behind bridge: 00002000-00003fff
Memory behind bridge: f3a00000-f3bfffff
Prefetchable memory behind bridge: e8000000-efffffff
Secondary status: 66Mhz- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B-
00: de 10 5c 00 07 01 a0 00 a2 01 04 06 00 00 01 00
10: 00 00 00 00 00 00 00 00 00 01 01 78 20 30 80 22
20: a0 f3 b0 f3 00 e8 f0 ef 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 0b 02
00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) (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 10
Bus: primary=00, secondary=08, subordinate=0a, sec-latency=0
I/O behind bridge: 00004000-00004fff
Memory behind bridge: f3c00000-f3dfffff
Secondary status: 66Mhz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort+ <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
Capabilities: <available only to root>
00: de 10 5d 00 47 01 10 00 a3 00 04 06 10 00 01 00
10: 00 00 00 00 00 00 00 00 00 08 0a 00 41 41 00 20
20: c0 f3 d0 f3 f1 ff 01 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 ff 00 03 00
00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) (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 10
Bus: primary=00, secondary=05, subordinate=07, sec-latency=0
Secondary status: 66Mhz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
Capabilities: <available only to root>
00: de 10 5d 00 47 01 10 00 a3 00 04 06 10 00 01 00
10: 00 00 00 00 00 00 00 00 00 05 07 00 f1 01 00 00
20: f0 ff 00 00 f1 ff 01 00 00 00 00 00 00 00 00 00
30: ff ff 00 00 40 00 00 00 00 00 00 00 ff 00 03 00
00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) (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 10
Bus: primary=00, secondary=02, subordinate=04, sec-latency=0
Secondary status: 66Mhz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
Capabilities: <available only to root>
00: de 10 5d 00 47 01 10 00 a3 00 04 06 10 00 01 00
10: 00 00 00 00 00 00 00 00 00 02 04 00 f1 01 00 00
20: f0 ff 00 00 f1 ff 01 00 00 00 00 00 00 00 00 00
30: ff ff 00 00 40 00 00 00 00 00 00 00 ff 00 03 00
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: <available only to root>
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-
Capabilities: <available only to root>
00: 22 10 03 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 f0 00 00 00 00 00 00 00 00 00 00 00
00:19.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: <available only to root>
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:19.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:19.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:19.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-
Capabilities: <available only to root>
00: 22 10 03 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 f0 00 00 00 00 00 00 00 00 00 00 00
00:1a.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: <available only to root>
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:1a.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:1a.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:1a.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-
Capabilities: <available only to root>
00: 22 10 03 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 f0 00 00 00 00 00 00 00 00 00 00 00
00:1b.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: <available only to root>
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:1b.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:1b.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:1b.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-
Capabilities: <available only to root>
00: 22 10 03 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 f0 00 00 00 00 00 00 00 00 00 00 00
01:03.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02) (prog-if
00 [VGA])
Subsystem: Hewlett-Packard Company: Unknown device 31fb
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: 127 (2000ns min), Cache Line Size 10
Interrupt: pin A routed to IRQ 193
Region 0: Memory at e8000000 (32-bit, prefetchable) [size=128M]
Region 1: I/O ports at 3000 [size=256]
Region 2: Memory at f3bf0000 (32-bit, non-prefetchable) [size=64K]
Capabilities: <available only to root>
00: 02 10 5e 51 87 01 90 02 02 00 00 03 10 7f 00 00
10: 08 00 00 e8 01 30 00 00 00 00 bf f3 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 fb 31
30: 00 00 00 00 50 00 00 00 00 00 00 00 0b 01 08 00
01:04.0 System peripheral: Compaq Computer Corporation Integrated Lights Out
Controller (rev 03)
Subsystem: Hewlett-Packard Company: Unknown device 3305
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-
Interrupt: pin A routed to IRQ 201
Region 0: I/O ports at 2800 [size=256]
Region 1: Memory at f3be0000 (32-bit, non-prefetchable) [size=512]
Capabilities: <available only to root>
00: 11 0e 03 b2 03 01 90 02 03 00 80 08 00 00 80 00
10: 01 28 00 00 00 00 be f3 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 05 33
30: 00 00 00 00 f0 00 00 00 00 00 00 00 0b 01 00 00
01:04.2 System peripheral: Compaq Computer Corporation Integrated Lights Out
Processor (rev 03)
Subsystem: Hewlett-Packard Company: Unknown device 3305
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: 120, Cache Line Size 10
Interrupt: pin B routed to IRQ 209
Region 0: I/O ports at 3400 [size=256]
Region 1: Memory at f3bd0000 (32-bit, non-prefetchable) [size=2K]
Region 2: Memory at f3bc0000 (32-bit, non-prefetchable) [size=8K]
Region 3: Memory at f3b00000 (32-bit, non-prefetchable) [size=512K]
Capabilities: <available only to root>
00: 11 0e 04 b2 17 01 90 02 03 00 80 08 10 78 80 00
10: 01 34 00 00 00 00 bd f3 00 00 bc f3 00 00 b0 f3
20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 05 33
30: 00 00 00 00 f0 00 00 00 00 00 00 00 0a 02 00 00
01:04.4 USB Controller: Hewlett-Packard Company: Unknown device 3300 (prog-if 00
[UHCI])
Subsystem: Hewlett-Packard Company: Unknown device 3305
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: 120
Interrupt: pin B routed to IRQ 209
Region 4: I/O ports at 3800 [size=32]
Capabilities: <available only to root>
00: 3c 10 00 33 45 01 90 02 00 00 03 0c 00 78 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 38 00 00 00 00 00 00 00 00 00 00 3c 10 05 33
30: 00 00 00 00 f0 00 00 00 00 00 00 00 0a 02 00 00
01:04.6 Class 0c07: Hewlett-Packard Company: Unknown device 3302 (prog-if 01)
Subsystem: Hewlett-Packard Company: Unknown device 3305
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-
Interrupt: pin A routed to IRQ 201
Region 0: Memory at f3af0000 (32-bit, non-prefetchable) [size=256]
Capabilities: <available only to root>
00: 3c 10 02 33 02 00 90 02 00 01 07 0c 00 00 80 00
10: 00 00 af f3 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 3c 10 05 33
30: 00 00 00 00 f0 00 00 00 00 00 00 00 0b 01 00 00
08:00.0 RAID bus controller: Hewlett-Packard Company Hewlett-Packard Smart Array
Controller (rev 03)
Subsystem: Hewlett-Packard Company: Unknown device 3234
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 10
Interrupt: pin A routed to IRQ 201
Region 0: Memory at f3d00000 (64-bit, non-prefetchable) [size=1M]
Region 2: I/O ports at 4000 [size=256]
Region 3: Memory at f3cf0000 (64-bit, non-prefetchable) [size=4K]
Capabilities: <available only to root>
00: 3c 10 30 32 47 04 10 00 03 00 04 01 10 00 00 00
10: 04 00 d0 f3 00 00 00 00 01 40 00 00 04 00 cf f3
20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 34 32
30: 00 00 00 00 b0 00 00 00 00 00 00 00 0b 01 00 00
40:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a4)
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: <available only to root>
00: de 10 5e 00 06 01 b0 00 a4 00 80 05 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 44 00 00 00 00 00 00 00 ff 00 00 00
40:01.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev b1)
Subsystem: nVidia Corporation: Unknown device cb84
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
00: de 10 d3 00 0f 00 a0 00 b1 00 80 05 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 de 10 84 cb
30: 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 00 00
40:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) (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 10
Bus: primary=40, secondary=4f, subordinate=51, sec-latency=0
Secondary status: 66Mhz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
Capabilities: <available only to root>
00: de 10 5d 00 47 01 10 00 a3 00 04 06 10 00 01 00
10: 00 00 00 00 00 00 00 00 40 4f 51 00 f1 01 00 00
20: f0 ff 00 00 f1 ff 01 00 00 00 00 00 00 00 00 00
30: ff ff 00 00 40 00 00 00 00 00 00 00 ff 00 03 00
40:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) (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 10
Bus: primary=40, secondary=4c, subordinate=4e, sec-latency=0
I/O behind bridge: 00005000-00005fff
Memory behind bridge: fdf00000-fdffffff
Prefetchable memory behind bridge: 00000000f3e00000-00000000f3e00000
Secondary status: 66Mhz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort+ <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
Capabilities: <available only to root>
00: de 10 5d 00 47 01 10 00 a3 00 04 06 10 00 01 00
10: 00 00 00 00 00 00 00 00 40 4c 4e 00 51 51 00 20
20: f0 fd f0 fd e1 f3 e1 f3 00 00 00 00 00 00 00 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 ff 00 03 00
40:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) (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 10
Bus: primary=40, secondary=49, subordinate=4b, sec-latency=0
Memory behind bridge: f8000000-fbffffff
Secondary status: 66Mhz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort+ <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
Capabilities: <available only to root>
00: de 10 5d 00 47 01 10 00 a3 00 04 06 10 00 01 00
10: 00 00 00 00 00 00 00 00 40 49 4b 00 f1 01 00 20
20: 00 f8 f0 fb f1 ff 01 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 ff 00 03 00
40:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) (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 10
Bus: primary=40, secondary=46, subordinate=48, sec-latency=0
Secondary status: 66Mhz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
Capabilities: <available only to root>
00: de 10 5d 00 47 01 10 00 a3 00 04 06 10 00 01 00
10: 00 00 00 00 00 00 00 00 40 46 48 00 f1 01 00 00
20: f0 ff 00 00 f1 ff 01 00 00 00 00 00 00 00 00 00
30: ff ff 00 00 40 00 00 00 00 00 00 00 ff 00 03 00
49:00.0 PCI bridge: Intel Corporation 41210 [Lanai] Serial to Parallel PCI
Bridge (A-Segment Bridge) (rev 09) (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 10
Bus: primary=49, secondary=4a, subordinate=4a, sec-latency=120
Memory behind bridge: f8000000-f9ffffff
Secondary status: 66Mhz+ FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
Capabilities: <available only to root>
00: 86 80 40 03 47 01 10 00 09 00 04 06 10 00 81 00
10: 00 00 00 00 00 00 00 00 49 4a 4a 78 f0 00 a0 22
20: 00 f8 f0 f9 f1 ff 01 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 44 00 00 00 00 00 00 00 00 00 03 00
49:00.2 PCI bridge: Intel Corporation 41210 [Lanai] Serial to Parallel PCI
Bridge (B-Segment Bridge) (rev 09) (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 10
Bus: primary=49, secondary=4b, subordinate=4b, sec-latency=120
Memory behind bridge: fa000000-fbffffff
Secondary status: 66Mhz+ FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
Capabilities: <available only to root>
00: 86 80 41 03 47 01 10 00 09 00 04 06 10 00 81 00
10: 00 00 00 00 00 00 00 00 49 4b 4b 78 f0 00 a0 22
20: 00 fa f0 fb f1 ff 01 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 44 00 00 00 00 00 00 00 00 00 03 00
4a:04.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5706 Gigabit
Ethernet (rev 02)
Subsystem: Hewlett-Packard Company: Unknown device 3070
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: 120 (16000ns min), Cache Line Size 10
Interrupt: pin A routed to IRQ 82
Region 0: Memory at f8000000 (64-bit, non-prefetchable) [size=32M]
Capabilities: <available only to root>
00: e4 14 4a 16 56 01 b0 02 02 00 00 02 10 78 00 00
10: 04 00 00 f8 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 3c 10 70 30
30: 00 00 00 00 40 00 00 00 00 00 00 00 05 01 40 00
4b:05.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5706 Gigabit
Ethernet (rev 02)
Subsystem: Hewlett-Packard Company: Unknown device 3070
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: 120 (16000ns min), Cache Line Size 10
Interrupt: pin A routed to IRQ 217
Region 0: Memory at fa000000 (64-bit, non-prefetchable) [size=32M]
Capabilities: <available only to root>
00: e4 14 4a 16 56 01 b0 02 02 00 00 02 10 78 00 00
10: 04 00 00 fa 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 3c 10 70 30
30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 01 40 00
4c:00.0 PCI bridge: PLX Technology, Inc. PEX 8111 PCI Express-to-PCI Bridge (rev
21) (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 10
Region 0: Memory at f3ef0000 (64-bit, prefetchable) [size=64K]
Bus: primary=4c, secondary=4d, subordinate=4d, sec-latency=127
I/O behind bridge: 00005000-00005fff
Memory behind bridge: fdf00000-fdffffff
Secondary status: 66Mhz- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
Capabilities: <available only to root>
00: b5 10 11 81 47 01 10 00 21 00 04 06 10 00 01 00
10: 0c 00 ef f3 00 00 00 00 4c 4d 4d 7f 50 50 00 22
20: f0 fd f0 fd 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
4d:04.0 Communication controller: Ulticom (Formerly DGM&S): Unknown device 0303
Subsystem: Ulticom (Formerly DGM&S): Unknown device 0303
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: 127 (1000ns max), Cache Line Size 10
Interrupt: pin A routed to IRQ 217
Region 0: Memory at fdff0000 (32-bit, non-prefetchable) [size=512]
Region 1: I/O ports at 5000 [size=256]
Region 2: Memory at fdfe0000 (32-bit, non-prefetchable) [size=16K]
Region 3: Memory at fdfd0000 (32-bit, non-prefetchable) [size=16K]
Capabilities: <available only to root>
00: d4 12 03 03 57 01 b0 02 00 00 80 07 10 7f 00 00
10: 00 00 ff fd 01 50 00 00 00 00 fe fd 00 00 fd fd
20: 00 00 00 00 00 00 00 00 00 00 00 00 d4 12 03 03
30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 01 00 04
MemTotal: 14328536 kB
MemFree: 13328108 kB
Buffers: 30856 kB
Cached: 845120 kB
SwapCached: 0 kB
Active: 295816 kB
Inactive: 628284 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 14328536 kB
LowFree: 13328108 kB
SwapTotal: 2096440 kB
SwapFree: 2096440 kB
Dirty: 336 kB
Writeback: 0 kB
Mapped: 56208 kB
Slab: 42936 kB
CommitLimit: 9260708 kB
Committed_AS: 122044 kB
PageTables: 2104 kB
VmallocTotal: 536870911 kB
VmallocUsed: 263468 kB
VmallocChunk: 536607223 kB
HugePages_Total: 0
HugePages_Free: 0
Hugepagesize: 2048 kB
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 65
model name : Dual-Core AMD Opteron(tm) Processor 8220
stepping : 3
cpu MHz : 1004.727
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
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 lm 3dnowext 3dnow pni cx16
bogomips : 2009.30
TLB size : 1088 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp [4] [5]
processor : 1
vendor_id : AuthenticAMD
cpu family : 15
model : 65
model name : Dual-Core AMD Opteron(tm) Processor 8220
stepping : 3
cpu MHz : 1004.727
cache size : 1024 KB
physical id : 1
siblings : 2
core id : 0
cpu cores : 2
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 lm 3dnowext 3dnow pni cx16
bogomips : 2009.30
TLB size : 1088 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp [4] [5]
processor : 2
vendor_id : AuthenticAMD
cpu family : 15
model : 65
model name : Dual-Core AMD Opteron(tm) Processor 8220
stepping : 3
cpu MHz : 1004.727
cache size : 1024 KB
physical id : 2
siblings : 2
core id : 0
cpu cores : 2
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 lm 3dnowext 3dnow pni cx16
bogomips : 2009.30
TLB size : 1088 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp [4] [5]
processor : 3
vendor_id : AuthenticAMD
cpu family : 15
model : 65
model name : Dual-Core AMD Opteron(tm) Processor 8220
stepping : 3
cpu MHz : 1004.727
cache size : 1024 KB
physical id : 3
siblings : 2
core id : 0
cpu cores : 2
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 lm 3dnowext 3dnow pni cx16
bogomips : 2009.30
TLB size : 1088 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp [4] [5]
processor : 4
vendor_id : AuthenticAMD
cpu family : 15
model : 65
model name : Dual-Core AMD Opteron(tm) Processor 8220
stepping : 3
cpu MHz : 1004.727
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
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 lm 3dnowext 3dnow pni cx16
bogomips : 2009.30
TLB size : 1088 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp [4] [5]
processor : 5
vendor_id : AuthenticAMD
cpu family : 15
model : 65
model name : Dual-Core AMD Opteron(tm) Processor 8220
stepping : 3
cpu MHz : 1004.727
cache size : 1024 KB
physical id : 1
siblings : 2
core id : 1
cpu cores : 2
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 lm 3dnowext 3dnow pni cx16
bogomips : 2009.30
TLB size : 1088 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp [4] [5]
processor : 6
vendor_id : AuthenticAMD
cpu family : 15
model : 65
model name : Dual-Core AMD Opteron(tm) Processor 8220
stepping : 3
cpu MHz : 1004.727
cache size : 1024 KB
physical id : 2
siblings : 2
core id : 1
cpu cores : 2
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 lm 3dnowext 3dnow pni cx16
bogomips : 2009.30
TLB size : 1088 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp [4] [5]
processor : 7
vendor_id : AuthenticAMD
cpu family : 15
model : 65
model name : Dual-Core AMD Opteron(tm) Processor 8220
stepping : 3
cpu MHz : 1004.727
cache size : 1024 KB
physical id : 3
siblings : 2
core id : 1
cpu cores : 2
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 lm 3dnowext 3dnow pni cx16
bogomips : 2009.30
TLB size : 1088 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp [4] [5]
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/cciss/c0d0p3
# initrd /initrd-version.img
#boot=/dev/cciss/c0d0
default=saved
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Red Hat Enterprise Linux AS (2.6.9-42.ELsmp)
savedefault
root (hd0,0)
kernel /vmlinuz-2.6.9-42.ELsmp ro root=LABEL=/ mem=16384M
# selinux=0 acpi=off mem=16384M
initrd /initrd-2.6.9-42.ELsmp.img
title Red Hat Enterprise Linux AS-up (2.6.9-42.EL)
savedefault
root (hd0,0)
kernel /vmlinuz-2.6.9-42.EL ro root=LABEL=/ selinux=0 acpi=off noacpi
initrd /initrd-2.6.9-42.EL.img
(In reply to comment #4) > what is this ? > " 59.EL5 (or newer) kernel from Oops. Sorry for the typo -- that should have read 59.EL4. It is the latest RHEL4 codebase which eventually will become RHEL4.6, RHEL4.7, etc.. > http://people.redhat.com/~jbaron/rhel4/ and retest? " > Thanks, P. We used the "59" kernel as you requested. The experiment failed. There was no difference in behavior. ---- To clarify, when we request a 64k block, we are expecting that the address of that 64k block to begin at an address that is on a 64k boundry. When we are on a machine with 16gig of memory, that does not occur. When we limit the memory of the machine to 4gig, then we do get what we expect. we are going to try RH5 when a machine frees up because we are curious. However, this will not be long term fix for us because our customers have stated that they wish to remain with RH4. To provide more detail, the chip on the board that we interface with across the PCI bus demands that the memory address be on a 64k byte boundry because the chip utilizes the lower bits of the address for its own purposes. The only potential workaround that we see is to allocate a 128k block of memory, and then move our pointer for the chip to the address of where the 64k boundry is. This should be workable in theory since there must be a 64k boundry somewhere within a 128k block of memory. Although we will have additional work to do so as to keep track of kernel pointers vs chip pointers. And, of course, we will waste half of the 128k of memory. ( we have not tried this yet since a machine is not available at the moment. ) --- Either way, we are still curious as to why the behavior of the pci_alloc_consistent() call changes when the amount of memory in the machine changes. William, what is the HP model # of this system? Thanks, P. William, Just to make sure I have this right: You want an 64k-aligned region of memory to be returned from pci_alloc_consistent. If that is the case, then you should know that pci_alloc_consistent does not guarantee alignment. It might be 16k aligned, it might be 64k, etc.. You must use the pci_pool_* functions to re-allocate memory within the memory region returned by pci_alloc_consistent. The pci_pool_create function allows one to set alignment requirements. P. The machine we have with 16gig of memory is a HP Proliant DL585 G2. It is big, expensive, and physically heavy. This is the machine that our customer has chosen for their deployments. "... you should know that pci_alloc_consistent does not guarantee alignment. It might be 16k aligned, it might be 64k, etc..." Where can I find the documentation that supports this statement ? We have found very little documentation on this API in our research. It is very odd that we would have been "just lucky" to be having this API work by giving us 64k boundries over the many machines and many deployments that we have had over the last 6 years. Granted, we have only attempted to use 16gig machines recently... It is still strange to us that the behavior of the API changes with the amount of memory allowed to be used by the kernel. ( We use the same physical box, and simply add the mem=x switch to the kernel command line in grub.conf . ) oops - I forgot to answer your question in #14 directly... Yes, we are expecting the return of pci_alloc_consistent() to be aligned on a 64k boundry. what happened to comments 12 & 13 on this thread ?? more related to comment 14... If you are suggesting that we have to create a pool of some type, then this pool is going to have to be bigger than the 64k bytes that we need because you are suggesting that the return will not be 64k bounded. This seems like a lot of work to get 1 64k chunk of memory. It seems that this idea is similar to the idea I put forth in comment 10. However using the pool APIs implies even more work. Hmmm ... DL585G2, I think we have one of these. Is your BIOS, etc., all up-to-date? I'm going to go off and run a few tests on the box. I'll ping you with results. P. I misunderstood what you were attempting to do. I got a bit confused. You are doing the following: pci_alloc_consistent(... size=64k, GFP_KERNEL); and are getting a return of a 16k-byte aligned value, correct? I thought you were doing the pci_alloc_consistent and then attempting to re-allocate 16k within that area.... P. Yes, the size input to our call of pci_alloc_consistent() is 64k. ( By the way, GFP_KERNEL is not a valid input to this call... ) Our DL585 machines arrived in our lab within the last 45 days. I'm told that the BIOS is the newest available - Feb 2007. ( I have not inspected this for myself yet as the machines are being used by someone else at the moment. ) bios info... version A07 Feb 27, 2007 (In reply to comment #22) > Yes, the size input to our call of pci_alloc_consistent() is 64k. > ( By the way, GFP_KERNEL is not a valid input to this call... ) Sorry, I was mixing up coherent and consistent :) I'll take a look at our dl585g2 when it becomes available. Could you cut-and-paste the exact pci_alloc_consistent call you're making (with the exact size value)? Thanks :) P. (In reply to comment #16) > > It is still strange to us that the behavior of the API changes > with the amount of memory allowed to be used by the kernel. > ( We use the same physical box, and simply add the mem=x switch > to the kernel command line in grub.conf . ) > It's not completely strange -- at least in my opinion. I'm going to dig through and see what I see, but I'm guessing that memory zone mapping will change drastically as you increase (more than double) the amount of memory you have in your system. ( cut & paste of code as requested )
.
.
.
/* here we call a wrapper to get the memory */
#define ACTUAL_DMA_SIZE 0x10000 /* 64 k alignment */
/* first do the board address list */
if (!(boardConfig->dmaBrdAddrList.virt_memoryp =
stream_pci_alloc_consistent((boardConfig->pciDev),
ACTUAL_DMA_SIZE, (dma_addr_t *)
boardConfig->dmaBrdAddrList.physical_mem)))
{
cmn_err(CE_CONT, "%s(%d): pcimb3_pci_alloc_consistent()
failed\n", __FUNCTION__, __LINE__);
return 1;
}
.
.
.
+++++++++++++++++++++++++++++++++++++++++++++
/* this is the wrapper code that actually calls the kernel */
caddr_t
stream_pci_alloc_consistent(stream_pci_dev_t *dev,
size_t size,
void *phys_addr)
{
dma_addr_t *dma_p = (dma_addr_t *)phys_addr;
/*caller will check for failure*/
return (caddr_t)pci_alloc_consistent(STREAM_CONVERT_TO_PCI_DEV(dev),
size, dma_p);
}/* stream_pci_alloc_consistent*/
Created attachment 216601 [details]
pci_alloc_consistent.stp
This script can be used to monitor calls to pci_alloc_consistent (really
dma_alloc_coherent since pci_alloc_consistent is inline it can't be probed) and
will scream and print a backtrace whenever you hit the bug you are seeing. You
may need to install systemtap if it's not installed already.
You can run it by doing the following:
# stap filname.stp
Feel free to capture the output if you like. You will obviously want to run
this before loading the module that causes the problem.
I am not familar with "systemtap". questions: 1) how do I verify that this tool is installed on my box ? 2) if the tool is not on the box, which package needs to be installed ? thanks You can probably just install it with an # up2date -i systemtap and up2date will take care of the the dependencies and install all the packages you need for the tool. After that you will need to install the kernel-debuginfo too. This can be downloaded from: http://updates.redhat.com/enterprise/4AS/en/os/Debuginfo/x86_64/RPMS/ Just install kernel-debuginfo rpm version that matches the one you are running. need some help...
What does this error mean ?
+++++++++++++++++
# cat pci_alloc_consistent.stp
probe kernel.function("dma_alloc_coherent").return
{
#printf(" address = 0x%x\n",$return);
if (($return & ~($size)) != $return) {
printf("INCORRECT MEMORY ALIGNMENT! ");
printf("dma_alloc_coherent: size = 0x%x address =
0x%x\n",$size,$return);
print_backtrace();
} else {
printf("dma_alloc_coherent: size = 0x%x address =
0x%x\n",$size,$return);
}
}
#
#
#
#
#
# stap -v ./pci_alloc_consistent.stp
Pass 1: parsed user script and 25 library script(s) in 120usr/0sys/137real ms.
semantic error: target variables not available to .return probes
semantic error: no match for probe point
while: resolving probe point kernel.function("dma_alloc_coherent").return
Pass 2: analyzed script: 0 probe(s), 1 function(s), 0 global(s) in
270usr/30sys/299real ms.
Pass 2: analysis failed. Try again with more '-v' (verbose) options.
#
#
# date
Fri Oct 5 11:17:03 EDT 2007
Created attachment 217641 [details]
list of probeable functions in my kernel
(In reply to comment #33) > Created an attachment (id=217641) [edit] > list of probeable functions in my kernel > I listed the probeable functions in my kernel, and placed the results in the attachment id=217641 dma_alloc_coherent is in the list. I found a workaround. Instead of asking for the values of the variables, I just removed them. Since I only have a limited number of calls to pci_alloc_consistent, it looks like this idea might pan out. I will post a good run where the memory is limited to 3gig, and then post a bad run where the memory is the full 16gig. Created attachment 217701 [details]
good run of stap - memory limited to 3 gig
the stap was executed with memory on the machine limited to 3 gig.
The exact stp file is listed at the end of the logfile
Created attachment 217711 [details]
bad run - 16 gig of memory used by the machine
in this run of the stp file,
the full 16 gig of memory was allowed to be used by the kernel.
My driver reported the error that it was expected to.
I do not understand why on the good run, the pci_alloc_consistent ( or dma_alloc_coherent ) was called twice, but on the bad run the routine was only called once. Great job getting it working! I think I know what is wrong with the script.
Can you try this as the script?
probe kernel.function("dma_alloc_coherent").return
{
printf("dma_alloc_coherent: size = 0x10000 address = 0x%x\n",$return);
print_backtrace();
}
That should work correctly for your instance and we might be able to get some
more info about the return address and might help us understand why it was
called twice -- any chance pci_alloc_consistent is being called twice by your code?
the machine is offline. I can not do this test tonight from home. I'll try Monday... +++ a question - what are you expecting to see as the return address ? Based on debug I inserted into my code, I know that the "bad" address is a multiple of 16k, not 64k. Each test reveals a different address, but it is always a multiple of 16k when the machine is configured for 16gig. Since the new script is just giving a backtrace ( which I believe will be the same backtrace as comment 38 ), what new information will be revealed by this test ? --- good run with 4gig of memory allowed on the box using stap script to return $return... # stap ./p2.stp dma_alloc_coherent: size = 0x10000 address =0x1001dbb0000 trace for 30764 (mount) 0xffffffff8012233c : kretprobe_trampoline+0x1/0x2 [] 0xffffffff8012233b : kretprobe_trampoline+0x0/0x2 [] 0xffffffffa059c06c : init_module+0x18106c/0x0 [nfs] 0xffffffffa04e813c : init_module+0xcd13c/0x0 [nfs] 0xffffffffa04e7f15 : init_module+0xccf15/0x0 [nfs] 0xffffffffa04e2cd1 : init_module+0xc7cd1/0x0 [nfs] 0xffffffffa04e7583 : init_module+0xcc583/0x0 [nfs] 0xffffffffa04e750b : init_module+0xcc50b/0x0 [nfs] 0xffffffff8017fa5d : get_sb_single+0x50/0x93 [] 0xffffffff8017fb41 : do_kern_mount+0xa1/0x179 [] 0xffffffff801951a0 : do_mount+0x69a/0x6e2 [] 0xffffffff801ea749 : __up_read+0x10/0x8b [] 0xffffffff80123ed3 : do_page_fault+0x23f/0x628 [] 0xffffffff80169ca3 : handle_mm_fault+0x175/0x568 [] 0xffffffff8018728a : __user_walk+0x5e/0x69 [] 0xffffffff80195543 : sys_mount+0xba/0x158 [] 0xffffffff8011026a : system_call+0x7e/0x83 [] dma_alloc_coherent: end dma_alloc_coherent: size = 0x10000 address =0x10079370000 trace for 30764 (mount) 0xffffffff8012233c : kretprobe_trampoline+0x1/0x2 [] 0xffffffff8012233b : kretprobe_trampoline+0x0/0x2 [] 0xffffffffa059c06c : init_module+0x18106c/0x0 [nfs] 0xffffffffa04e813c : init_module+0xcd13c/0x0 [nfs] 0xffffffffa04e7f15 : init_module+0xccf15/0x0 [nfs] 0xffffffffa04e2cd1 : init_module+0xc7cd1/0x0 [nfs] 0xffffffffa04e7583 : init_module+0xcc583/0x0 [nfs] 0xffffffffa04e750b : init_module+0xcc50b/0x0 [nfs] 0xffffffff8017fa5d : get_sb_single+0x50/0x93 [] 0xffffffff8017fb41 : do_kern_mount+0xa1/0x179 [] 0xffffffff801951a0 : do_mount+0x69a/0x6e2 [] 0xffffffff801ea749 : __up_read+0x10/0x8b [] 0xffffffff80123ed3 : do_page_fault+0x23f/0x628 [] 0xffffffff80169ca3 : handle_mm_fault+0x175/0x568 [] 0xffffffff8018728a : __user_walk+0x5e/0x69 [] 0xffffffff80195543 : sys_mount+0xba/0x158 [] 0xffffffff8011026a : system_call+0x7e/0x83 [] dma_alloc_coherent: end The purpose of this script it to help us capture all calls to pci_alloc_consistent so that we can examine everything more closely and try to make sure this isn't something unique to your setup (which I'm guessing it's not). It also allows us to test this on a system (yours or ours) without constantly recompiling the kernel or modules (since we don't have access to your module). while trying to get the "bad" run, I see, so far, 1 hit instead of 2 in your debug code. I'm guessing this is an ethernet driver. However, my code is still complaining about an error while your code shows no output that can be correlated to my output. Therefore, I'm going to have to add some print statements back into my driver... ( Translation - the stap debug code does appear to "hit" when my driver declares a failure. ) more later please ignore comment 44. It appears that I am not awake yet... --------- I finally did find 2 calls to pci_alloc_consistent in my driver. --------- I'm still trying to get a bad run with meaningful data... Here is the output of the "bad" run. The trigger only hits once because my code declares failure, and the second attempt at pci_alloc_consistent() is not performed. This data reveals that the output of pci_alloc_consistent() is correct. Therefore, I now have to go back to my code and look hard at the error logic. +++++++++++++++ dma_alloc_coherent: size = 0x10000 address =0x102605f0000 trace for 14246 (mount) 0xffffffff8012233c : kretprobe_trampoline+0x1/0x2 [] 0xffffffff8012233b : kretprobe_trampoline+0x0/0x2 [] 0xffffffffa02d143c : momOpen+0xf4/0x150 [strmfs_mod] 0xffffffffa022513c : init_module+0x713c/0xa9000 [nfs] 0xffffffffa0224f15 : init_module+0x6f15/0xa9000 [nfs] 0xffffffffa021fcd1 : init_module+0x1cd1/0xa9000 [nfs] 0xffffffffa0224583 : init_module+0x6583/0xa9000 [nfs] 0xffffffffa022450b : init_module+0x650b/0xa9000 [nfs] 0xffffffff8017fa5d : get_sb_single+0x50/0x93 [] 0xffffffff8017fb41 : do_kern_mount+0xa1/0x179 [] 0xffffffff801951a0 : do_mount+0x69a/0x6e2 [] 0xffffffff801ea749 : __up_read+0x10/0x8b [] 0xffffffff80123ed3 : do_page_fault+0x23f/0x628 [] 0xffffffff80169ca3 : handle_mm_fault+0x175/0x568 [] 0xffffffff8018728a : __user_walk+0x5e/0x69 [] 0xffffffff80195543 : sys_mount+0xba/0x158 [] 0xffffffff8011026a : system_call+0x7e/0x83 [] dma_alloc_coherent: end Sounds good, William. Keep us posted on what you find.
My error logic appears to be fine.
Our debug data is incomplete.
Recall that the formal prototype for pci_alloc_consistent()
is...
void *pci_alloc_consistent( struct pci_dev *dev,
size_t size,
dma_addr_t *dma_handle) ;
There are actually two returns from this function!
The value of *dma_handle is the value that is not 64k bounded.
Another way to look at this prototype is:
void *pci_alloc_consistent( struct pci_dev *dev,
size_t size,
void *phys_addr) ; <------------ !!
The value that we captured in the debug is the
formal return parameter, which is the virtual memory address.
The value we do not see from the stp debug script
is the value of the physical memory address,
which is returned as *dma_handle.
Our program is checking that the PHYSICAL address is 64k bounded.
This is not occurring when 16gig of memory is in the machine.
Ah, now we are getting somewhere. :-) The systemtap script can be easily modified to see if this happens on other systems as well. I'll put one together and test it on my system and see what results I get. Sorry I've been slow with this -- I'll get this working next week. I've been playing around with a stap script for this without much luck. I can't seem to set probe points on specific filename/line #'s so I may have to instrument a special kernel to gather this info. I'm going to speak with someone on Monday and find out if this is the case, and if so, I'll spin some test kernels that we can use to gather this info. So I instrumented an upstream kernel's pci_alloc_consistent like this (the same
could easily apply to rhel4)
diff --git a/include/asm-generic/pci-dma-compat.h
b/include/asm-generic/pci-dma-compat.h
index 25c10e9..db121a8 100644
--- a/include/asm-generic/pci-dma-compat.h
+++ b/include/asm-generic/pci-dma-compat.h
@@ -19,7 +19,9 @@ static inline void *
pci_alloc_consistent(struct pci_dev *hwdev, size_t size,
dma_addr_t *dma_handle)
{
- return dma_alloc_coherent(hwdev == NULL ? NULL : &hwdev->dev, size,
dma_handle, GFP_ATOMIC);
+ void *retval = dma_alloc_coherent(hwdev == NULL ? NULL : &hwdev->dev,
size, dma_handle, GFP_ATOMIC);
+ printk(KERN_CRIT "p_a_c: return = 0x%lx *dma_handle =
0x%lx\n",retval,*dma_handle);
+ return retval;
}
static inline void
when I use a device driver that is setup to operate similar to yours, I seem to
get addresses on the correct boundries with mem=4096M and without (this system
has 16G of memory and is also an AMD system).
p_a_c: return = 0xffff810104cda000 *dma_handle = 0x104cda000
p_a_c: return = 0xffff810104c66000 *dma_handle = 0x104c66000
p_a_c: return = 0xffff81000f8e0000 *dma_handle = 0xf8e0000
p_a_c: return = 0xffff81000f8e8000 *dma_handle = 0xf8e8000
p_a_c: return = 0xffff81000f8f0000 *dma_handle = 0xf8f0000
p_a_c: return = 0xffff81000f900000 *dma_handle = 0xf900000
p_a_c: return = 0xffff81000f8f0000 *dma_handle = 0xf8f0000
p_a_c: return = 0xffff810010108000 *dma_handle = 0x10108000
p_a_c: return = 0xffff81000f8e0000 *dma_handle = 0xf8e0000
p_a_c: return = 0xffff81000f900000 *dma_handle = 0xf900000
Great ! You recreated the problem. ( The last 4 hex digits of *dma_handle is expected to be '0000'. Your data shows four cases where the result does not meet this goal. ) Actually, William, that was for all allocations, not a 64k allocation. I hacked up a driver and now get the following output. Remember that I am doing all of this on an upstream kernel (2.6.24-rc1), so this isn't the best indicator that a problem won't happen on RHEL4. tehuti: 0x10ed0000 = pci_alloc_consistent(dev, 0x10000, 0x10ed0000) tehuti: 0x10ee0000 = pci_alloc_consistent(dev, 0x10000, 0x10ee0000) tehuti: 0x10ef0000 = pci_alloc_consistent(dev, 0x10000, 0x10ef0000) tehuti: 0x10f00000 = pci_alloc_consistent(dev, 0x10000, 0x10f00000) tehuti: 0x10f10000 = pci_alloc_consistent(dev, 0x10000, 0x10f10000) tehuti: 0x10f20000 = pci_alloc_consistent(dev, 0x10000, 0x10f20000) tehuti: 0x10f30000 = pci_alloc_consistent(dev, 0x10000, 0x10f30000) tehuti: 0x10f40000 = pci_alloc_consistent(dev, 0x10000, 0x10f40000) tehuti: 0x10f50000 = pci_alloc_consistent(dev, 0x10000, 0x10f50000) tehuti: 0x10f60000 = pci_alloc_consistent(dev, 0x10000, 0x10f60000) tehuti: 0x10f70000 = pci_alloc_consistent(dev, 0x10000, 0x10f70000) tehuti: 0x10f80000 = pci_alloc_consistent(dev, 0x10000, 0x10f80000) tehuti: 0x10f90000 = pci_alloc_consistent(dev, 0x10000, 0x10f90000) tehuti: 0x10fa0000 = pci_alloc_consistent(dev, 0x10000, 0x10fa0000) tehuti: 0x10fb0000 = pci_alloc_consistent(dev, 0x10000, 0x10fb0000) tehuti: 0x10fc0000 = pci_alloc_consistent(dev, 0x10000, 0x10fc0000) tehuti: 0x10fd0000 = pci_alloc_consistent(dev, 0x10000, 0x10fd0000) tehuti: 0x10fe0000 = pci_alloc_consistent(dev, 0x10000, 0x10fe0000) tehuti: 0x10ff0000 = pci_alloc_consistent(dev, 0x10000, 0x10ff0000) tehuti: 0x11000000 = pci_alloc_consistent(dev, 0x10000, 0x11000000) tehuti: 0x11010000 = pci_alloc_consistent(dev, 0x10000, 0x11010000) tehuti: 0x11020000 = pci_alloc_consistent(dev, 0x10000, 0x11020000) tehuti: 0x11030000 = pci_alloc_consistent(dev, 0x10000, 0x11030000) Everything seems to be working out well and this system currently has 8G or RAM. MemTotal: 8266748 kB MemFree: 5888532 kB Buffers: 75220 kB Cached: 1895920 kB SwapCached: 0 kB Active: 1684912 kB Inactive: 527032 kB SwapTotal: 2031608 kB SwapFree: 2031608 kB Dirty: 40 kB Can you share some of your addresses with us when you get this failure? I'm wondering how the physical addresses differ when booting with or without mem=4096M. I have to schedule time on the box. I will gather the data you request. I'm actually re-installing my system with RHEL4.4 so I can test some as well -- I should have some results in a little while. interesting info... My box has multiple disks on it so we can switch between the various OSs that we support. When I got the box, it contained RH5 64 bit ( 2.6.18-8.e15 ( Tikanga ) ). My problem does not appear in this configuration. I'm going back to RH 4 now... I hacked up the forcedeth driver on this box (a RHEL4.5 install with the kernel close to what we will ship with 4.6 and still cannot reproduce the error you are seeing). forcedeth: ex: 0x8b50000 = pci_alloc_consistent(dev, 0x10000, 0x8b50000) forcedeth: ex: 0x4a00000 = pci_alloc_consistent(dev, 0x10000, 0x4a00000) forcedeth: ex: 0xa490000 = pci_alloc_consistent(dev, 0x10000, 0xa490000) forcedeth: ex: 0x8450000 = pci_alloc_consistent(dev, 0x10000, 0x8450000) forcedeth: ex: 0xaaf0000 = pci_alloc_consistent(dev, 0x10000, 0xaaf0000) forcedeth: ex: 0x1ab20000 = pci_alloc_consistent(dev, 0x10000, 0x1ab20000) forcedeth: ex: 0x17a20000 = pci_alloc_consistent(dev, 0x10000, 0x17a20000) forcedeth: ex: 0x1ab50000 = pci_alloc_consistent(dev, 0x10000, 0x1ab50000) forcedeth: ex: 0x16d00000 = pci_alloc_consistent(dev, 0x10000, 0x16d00000) forcedeth: ex: 0x14360000 = pci_alloc_consistent(dev, 0x10000, 0x14360000) forcedeth: ex: 0x14320000 = pci_alloc_consistent(dev, 0x10000, 0x14320000) forcedeth: ex: 0x15d40000 = pci_alloc_consistent(dev, 0x10000, 0x15d40000) forcedeth: ex: 0x17af0000 = pci_alloc_consistent(dev, 0x10000, 0x17af0000) forcedeth: ex: 0x142a0000 = pci_alloc_consistent(dev, 0x10000, 0x142a0000) forcedeth: ex: 0x177e0000 = pci_alloc_consistent(dev, 0x10000, 0x177e0000) forcedeth: ex: 0x176a0000 = pci_alloc_consistent(dev, 0x10000, 0x176a0000) forcedeth: ex: 0x1ba30000 = pci_alloc_consistent(dev, 0x10000, 0x1ba30000) forcedeth: ex: 0x144c0000 = pci_alloc_consistent(dev, 0x10000, 0x144c0000) forcedeth: ex: 0x3130000 = pci_alloc_consistent(dev, 0x10000, 0x3130000) forcedeth: ex: 0x2f50000 = pci_alloc_consistent(dev, 0x10000, 0x2f50000) forcedeth: ex: 0xfbab0000 = pci_alloc_consistent(dev, 0x10000, 0xfbab0000) forcedeth: ex: 0x1a80000 = pci_alloc_consistent(dev, 0x10000, 0x1a80000) forcedeth: ex: 0x2d80000 = pci_alloc_consistent(dev, 0x10000, 0x2d80000) forcedeth: ex: 0xaf00000 = pci_alloc_consistent(dev, 0x10000, 0xaf00000) forcedeth: ex: 0xbae0000 = pci_alloc_consistent(dev, 0x10000, 0xbae0000) forcedeth: ex: 0x37b0000 = pci_alloc_consistent(dev, 0x10000, 0x37b0000) forcedeth: ex: 0x1b360000 = pci_alloc_consistent(dev, 0x10000, 0x1b360000) forcedeth: ex: 0xa6d0000 = pci_alloc_consistent(dev, 0x10000, 0xa6d0000) forcedeth: ex: 0x1ca60000 = pci_alloc_consistent(dev, 0x10000, 0x1ca60000) forcedeth: ex: 0xaca0000 = pci_alloc_consistent(dev, 0x10000, 0xaca0000) forcedeth: ex: 0x12d0000 = pci_alloc_consistent(dev, 0x10000, 0x12d0000) forcedeth: ex: 0x1c960000 = pci_alloc_consistent(dev, 0x10000, 0x1c960000) MemTotal: 8226676 kB MemFree: 6328120 kB Buffers: 114332 kB Cached: 1584944 kB SwapCached: 0 kB Active: 1338956 kB Inactive: 404148 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 8226676 kB Linux dhcp231-119.rdu.redhat.com 2.6.9-65.EL.gtest.33 #1 Thu Nov 1 16:08:41 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux on a RH 4 update 4 ( 64bit ) box with 16gig of ram, here are the values that I am getting... run a Nov 1 16:56:38 boeing kernel: pcimb3_dma_init(14445): *tmp_p = 0000000004066000 Nov 1 16:56:38 boeing kernel: pcimb3_dma_init(14461): *tmp_p = 0000000004066000 run b Nov 1 17:10:51 boeing kernel: pcimb3_dma_init(14445): *tmp_p = 0000000004076000 Nov 1 17:10:51 boeing kernel: pcimb3_dma_init(14461): *tmp_p = 0000000004076000 run c Nov 1 17:12:18 boeing kernel: pcimb3_dma_init(14445): *tmp_p = 0000000004086000 Nov 1 17:12:18 boeing kernel: pcimb3_dma_init(14461): *tmp_p = 0000000004086000 reboot run d Nov 1 17:16:03 boeing kernel: pcimb3_dma_init(14445): *tmp_p = 0000000004064000 Nov 1 17:16:03 boeing kernel: pcimb3_dma_init(14461): *tmp_p = 0000000004064000 run e Nov 1 17:18:00 boeing kernel: pcimb3_dma_init(14445): *tmp_p = 0000000004074000 Nov 1 17:18:00 boeing kernel: pcimb3_dma_init(14461): *tmp_p = 0000000004074000 Since the last 4 hex digits are not '0000', I declare an error. Created attachment 246651 [details]
sysreport for 16gig rh4.4 machine 64bit
this is the sysreport for the machine that is
returning the unexpected values from pci_alloc_consistent().
This is a RH4.4 64 bit machine with 16gig of memory.
Ah-ha! It looks like I recreated your issue with an older kernel: forcedeth: 0x3e7b0000 = pci_alloc_consistent(dev, 0x10000, 0xc0c12000) I was running 2.6.9-55 on that one, so I'll see if I can sift through the changelogs to find the patch/bug that may have fixed this one. Can you test a later kernel for me? On of my test kernels would be fine as it's close to what will be used for RHEL4.6. http://people.redhat.com/agospoda/#rhel4 Time on the 16gig machine is difficult to schedule. I'll see what I can do. -- How does this request differ from the kernel used in comment 7 ? So far, we have run these tests to date... 2.6.9-42 ( RH 4 update 4 ) failed 2.6.9.55 ( RH 4 update 5 ) failed 2.6.9.59ish ( from comment 7 ) failed 2.6.18-8.e15 ( RH 5 Tikanga ) pass Well there have been plenty of changes between the latest RHEL4 kernels (2.6.9-65) and whatever you tested last, but I've yet to pinpoint one change that may have resolved this. My inability to use systemtap to accurately grab the info is tough too since that means I need to recompile a driver each time I want to test a different snapshot. I feel confident that if tests showing -65 resolves this issue that I can narrow it down. Of the bugs that seem like they could be related, this one sticks out. Fixed in -60 https://bugzilla.redhat.com/show_bug.cgi?id=294981 It seems like a possibility based on the problem at hand. regarding 294981, I received an "access denied" message when I tried to view it. regarding testing an experimental kernel, I've been informed that the 16 gig machines will not be available to me until 11/19/07 at the earliest due to company delivery commitments That's OK. I'll continue to test some different patches and see if I can come up with 'the one' that seems to resolve this issue on the latest RHEL4 builds Please point me to the kernel you wish me to test. I checked one link, but only found "68" kernels Anything on my people page should be fine. using the "68.2" kernel from http://people.redhat.com/agospoda/#rhel4, the test failed. So now we know: 2.6.9-42 ( RH 4 update 4 ) failed 2.6.9.55 ( RH 4 update 5 ) failed 2.6.9.59ish ( from comment 7 ) failed 2.6.9.68.2 ( from comment 62 ) failed 2.6.18-8.e15 ( RH 5 Tikanga ) pass also, 2.6.9.67 fails ( all of these are 64 bit versions ) I had to release the machine for other projects. William, I'm *truly* sorry that I haven't narrowed down this problem yet. In the past I discussed this with a few others, but we didn't come up with anything meaningful. I'd like to get this resolved for the next update, so I'm going to bring in a few other folks to help me look at this. William, One thought whem talking to someone is that the iommu could be in-play here. Can you try and boot with iommu=off on the kernel command line and see if that makes a difference. Thanks. on the hp proliant dl585 machine with 16 gig of memory, the machine panic'd during bootup when I added " iommu=off " to the kernel command line in the grub.conf file. This was using a 2.6.9.67 64bit kernel. Panic'd, eh? You didn't happen to capture the output from that did you? "Kernel panic - not syncing: PCI-DMA: high address but no IOMMU" Created attachment 296071 [details] high address but no IOMMU - first pic screen picture #1 of error message ( related to comment 78 ) Created attachment 296072 [details]
high address but no IOMMU - #2
second screen capture of
"high address but no IOMMU"
Comment on attachment 296072 [details] high address but no IOMMU - #2 related to comment 78 any news on this topic ? Created attachment 302376 [details]
possible-rhel4-gart-fix.patch
I was looking at this again today and chatting with someone else when they
suggested the attached patch that was added during 2.6.17 development.
It seems like this is a decent candidate since it expands the space to search
for valid memory. Can you give this a try?
msg received. I have submitted a request to get time on our 16gig-of-memory machine. Hopefully the end of this week... My test kernels have been updated to include a patch for this bugzilla. http://people.redhat.com/agospoda/#rhel4 Please test them and report back your results. Just got the machines today ( 4/21... ) more status later... using 2.6.9-69.EL.gtest.43smp, the test failed. ...same errors... Created attachment 310803 [details]
Module to reproduce issue
William,
Please compile and test the following module on your system and let us know the
results.
I am going to book time on a 64G dl-585-g2 in RDU to see if I can reproduce it
using the attached module.
(Makefile will be attached next)
P.
Created attachment 310807 [details]
Makefile for prarit.c
I was able to reproduce Ulticom's issue by loading my module (see comments #97 & #98) on a 64G DL585 G2. Output from my module: addr[0] = 00000103f4220000 dma_handle[0] = 40a1000 INCORRECT ALIGNMENT to 10000 Interesting that this doesn't appear to happen @ 8G... P. Created attachment 310860 [details]
new prarit.c module
William, please test this new module ASAP and let me know the results. I
noticed in my output that all returned addresses were above the 4G mark, so I
bumped the dma mask.
This module explicitly obsoletes the previous module code.
P.
I am currently out of the office. I will get to this upon my return the week of July 7. After looking into this over the weekend and checking with lwoodman regarding alignment requirements it turns out that my initial thoughts regarding pci_alloc_consistent were correct. * pci_alloc_consistent does not guarantee alignment to the size requested * If a user/driver requires a specific alignment the user/driver must use PCI (or DMA) pool functions. That, AFAICT, is the only way to guarantee DMA alignment requests. P. hmmm... This is very strange that the behavior would change based on the amount of memory in the machine. So, all these years, my driver is running my luck ? ... Are you saying that my only option is to do what is described in comment 10 ? ( request twice as much as I need, and find the boundry within the allocation that I got back from the call... ) I found the "pool" documentation. I'll have to play with this as an experiment ( when I can get time on the 16gig machine... I'm still waiting to try the experiment from comment 100... ) I found this statement in the DMA-mapping.txt file. It seems to me that this information conflicts with the information presented in comment 103... please advise... +++++++++++++++++++++ . . . pci_alloc_consistent returns two values: the virtual address which you can use to access it from the CPU and dma_handle which you pass to the card. The cpu return address and the DMA bus master address are both guaranteed to be aligned to the smallest PAGE_SIZE order which is greater than or equal to the requested size. This invariant exists (for example) to guarantee that if you allocate a chunk which is smaller than or equal to 64 kilobytes, the extent of the buffer you receive will not cross a 64K boundary. ... just an FYI, the date on the DMA-mapping.txt file is Oct 18, 2004. This file is part of RH4AS. On a RH5AS system, the file is dated Sep 19, 2006. Both versions of the file appear to have the same language when referring to pci_alloc_consistent(). Hi William,
Good catch! I think you hit the nail on the head when you noted that RHEL4
added the dma-mapping.txt sometime after the release of RHEL4. I suspect that
no one proof read the new document before it was committed :(. I'll probably
write up a patch to remove the conflicting comments in dma-mapping.txt.
As to the other question, "Why does this work if I bump the dma mask?" ...
pci_alloc_consistent() calls dma_alloc_coherent()
dma_alloc_coherent() executes the following code:
memory = dma_alloc_pages(dev, gfp, get_order(size));
.
.
.
int high, mmu;
bus = virt_to_bus(memory);
high = (bus + size) >= dma_mask; <<< by bumping the dma_mask,
you are simply increasing
this value. Therefore,
high = 0 (always).
mmu = high;
if (force_iommu && !(gfp & GFP_DMA))
mmu = 1;
if (no_iommu || dma_mask < 0xffffffffUL) {
if (high) {
if (!(gfp & GFP_DMA)) {
gfp |= GFP_DMA;
free_pages((unsigned long)memory,
get_order(size));
goto again;
}
goto free;
}
mmu = 0;
}
memset(memory, 0, size);
if (!mmu) {
*dma_handle = virt_to_bus(memory);
return memory; <<< we always return here because mmu=0
}
In the case that that high evaluates to 1, we end up at another method of
getting a dma area,
*dma_handle = dma_map_area(dev, bus, size, PCI_DMA_BIDIRECTIONAL, 0);
The call to dma_map_area *does not guarantee* any alignment. It simply queries
the iommu for an empty area and returns pointers to the area (virtual and a dma
handle).
(The function, dma_alloc_coherent is found in arch/x86_64/kernel/pci-gart.c)
Why does it seem like this suddenly broke in RHEL4?
As you add memory the likelihood of the value of "high" being calculated as 1
gets larger because the bus value gets larger.
Why does this work in RHEL5?
RHEL5 uses multiple DMA address ranges.
What is the right thing to do in RHEL4?
I would suggest using the dma pool functions, however, if you feel "safe" in
bumping the dma_mask feel free to do that instead...
P.
just an FYI, the date on the DMA-mapping.txt file is Oct 18, 2004. This file is part of RH4AS. On a RH5AS system, the file is dated Sep 19, 2006. Both versions of the file appear to have the same language when referring to pci_alloc_consistent(). oops - comment 111 should be deleted. I pushed the wrong button on my browser... (In reply to comment #112) > oops - comment 111 should be deleted. > I pushed the wrong button on my browser... > No problem William :) P. in response to comment 100, here is the output of the prarit.ko driver when the machine is configured to use only 4 gig of memory... Jul 8 11:36:21 boeing kernel: addr[0] = 000001005bc30000 Jul 8 11:36:21 boeing kernel: dma_handle[0] = 5bc30000 Jul 8 11:36:21 boeing kernel: addr[1] = 000001005c680000 Jul 8 11:36:21 boeing kernel: dma_handle[1] = 5c680000 Jul 8 11:36:21 boeing kernel: addr[2] = 000001005cea0000 Jul 8 11:36:21 boeing kernel: dma_handle[2] = 5cea0000 Jul 8 11:36:21 boeing kernel: addr[3] = 000001005c500000 Jul 8 11:36:21 boeing kernel: dma_handle[3] = 5c500000 Jul 8 11:36:21 boeing kernel: addr[4] = 000001005b700000 Jul 8 11:36:21 boeing kernel: dma_handle[4] = 5b700000 Jul 8 11:36:21 boeing kernel: addr[5] = 000001005d260000 Jul 8 11:36:21 boeing kernel: dma_handle[5] = 5d260000 Jul 8 11:36:21 boeing kernel: addr[6] = 000001005cfd0000 Jul 8 11:36:21 boeing kernel: dma_handle[6] = 5cfd0000 Jul 8 11:36:21 boeing kernel: addr[7] = 000001005c230000 Jul 8 11:36:21 boeing kernel: dma_handle[7] = 5c230000 Jul 8 11:36:21 boeing kernel: addr[8] = 000001005c5c0000 Jul 8 11:36:21 boeing kernel: dma_handle[8] = 5c5c0000 Jul 8 11:36:21 boeing kernel: addr[9] = 000001005f020000 Jul 8 11:36:21 boeing kernel: dma_handle[9] = 5f020000 Now I have configured the machine for 16 gig... Here is the output. ( I do not see any errors being reported... ) Jul 8 11:43:53 boeing kernel: addr[0] = 000001027aab0000 Jul 8 11:43:53 boeing kernel: dma_handle[0] = 27aab0000 Jul 8 11:43:53 boeing kernel: addr[1] = 000001027aaa0000 Jul 8 11:43:53 boeing kernel: dma_handle[1] = 27aaa0000 Jul 8 11:43:53 boeing kernel: addr[2] = 000001027aac0000 Jul 8 11:43:53 boeing kernel: dma_handle[2] = 27aac0000 Jul 8 11:43:53 boeing kernel: addr[3] = 000001027aad0000 Jul 8 11:43:53 boeing kernel: dma_handle[3] = 27aad0000 Jul 8 11:43:53 boeing kernel: addr[4] = 000001027aae0000 Jul 8 11:43:53 boeing kernel: dma_handle[4] = 27aae0000 Jul 8 11:43:53 boeing kernel: addr[5] = 000001027aaf0000 Jul 8 11:43:53 boeing kernel: dma_handle[5] = 27aaf0000 Jul 8 11:43:53 boeing kernel: addr[6] = 000001027ab00000 Jul 8 11:43:53 boeing kernel: dma_handle[6] = 27ab00000 Jul 8 11:43:53 boeing kernel: addr[7] = 000001027ab10000 Jul 8 11:43:53 boeing kernel: dma_handle[7] = 27ab10000 Jul 8 11:43:53 boeing kernel: addr[8] = 000001027ab20000 Jul 8 11:43:53 boeing kernel: dma_handle[8] = 27ab20000 Jul 8 11:43:53 boeing kernel: addr[9] = 000001027ab30000 Jul 8 11:43:53 boeing kernel: dma_handle[9] = 27ab30000 I did confirm that the machine is using 16 gig via /proc/meminfo. AND, my driver also failed ( as it has been... ) Please note that in comment 115, the DMA mask was for 64 bit operation. I reran the test, but this time the coherent_dma_mask was set for 32bits. The prarit.ko test driver reported a failure in this case... Jul 8 11:49:15 boeing kernel: addr[0] = 000001016e500000 Jul 8 11:49:15 boeing kernel: dma_handle[0] = 40d3000 Jul 8 11:49:15 boeing kernel: INCORRECT ALIGNMENT to 10000 So this reveals the problem that my driver is having... I tried changing the input to pci_set_dma_mask() and pci_set_consistent_dma_mask() from 32bit to 64bit. My driver still failed.
I need some help on this "pool" stuff.
Given this MAN page info ( below ), I am having trouble
determining the correct values for the input parameters.
If I want a 64k block of memory that must start on a 64k boundry,
what are the correct values for "size","align", and "allocation" ?
64k, 64k, & 64k
or
64k, 64k, & 0
or
something else ??
Also, do I need to pre-size this pool in anyway ?
For example, I know that I need about 16 of these 64k block allocations.
Do I have to tell the kernel in some way about my need for 16, or
is this "pool" of 'near infinite' size such that I can call
pci_pool_alloc( dma_pool_alloc ) as many times as I wish ??
thanks...
++++++++++++++++++++++++++++
NAME
dma_pool_create - Creates a pool of consistent memory blocks, for dma.
SYNOPSIS
struct dma_pool * dma_pool_create (const char * name, struct device * dev,
size_t size, size_t align, size_t allocation);
ARGUMENTS
name
name of pool, for diagnostics
dev
device that will be doing the DMA
size
size of the blocks in this pool.
align
alignment requirement for blocks; must be a power of two
allocation
returned blocks won't cross this boundary (or zero)
Hi William,
I think you want to do the following:
reichs_pool = pci_pool_create("reich's device", &reichs_dev,
0x10000 /* 64K in size */,
0x10000 /* 64K byte aligned */,
0x10000 /* don't cross a 64K boundary */);
--- aside
I suppose in this case the last argument could be zero. AFAICT, doing a 64K
size that is 64K byte aligned will return you a pointer that doesn't cross a
64K boundary ...
--- end aside
and then do
addr = dma_pool_alloc(reichs_pool, GFP_ATOMIC, &dma_handle);
which should return you
addr (64K in size, aligned to 0x10000, and doesn't cross a 64K boundary)
dma_handle = physical pointer usable by device that is aligned to 0x10000
P.
the "pool" stuff did not work on my 16gig machine.
Same symptoms as before
- when the memory is set to 4gig or less, my memory allocations are
bounded at the correct 64k boundry.
- when the memory is set to 16gig, my memory allocations are
not on a 64k boundry.
I tried using two versions of the pool create:
reichs_pool = pci_pool_create("reich's device", &reichs_dev,
0x10000 /* 64K in size */,
0x10000 /* 64K byte aligned */,
0x10000 /* don't cross a 64K boundary */);
and
reichs_pool = pci_pool_create("reich's device", &reichs_dev,
0x10000 /* 64K in size */,
0x10000 /* 64K byte aligned */,
0 ;
same results...
report #454417 has been created to update documentation it is interesting to note that as I continue to run experiments with the pci_alloc_consistent(), the virtual address IS coming back 64k aligned, but the physical address is not. ( I need the physical address to be aligned... ) (In reply to comment #124) > > it is interesting to note that as I continue to run experiments with the > pci_alloc_consistent(), the virtual address IS coming back 64k aligned, but the > physical address is not. > ( I need the physical address to be aligned... ) Yes -- that was noted previously and is tested for in the prarit.c module. P. William, can we get some simple details about your device? Is it a 32-bit or 64-bit device? What is the dma_mask set to for this device? we have a 32bit device. We use the 32 bit dma mask. Referring to other comments ( #1 , #117 & #118 ) in this thread, #define DMA_32BIT_MASK 0x00000000ffffffffULL u64 stream_dma_32bit_mask = DMA_32BIT_MASK ; And for completeness, #define DMA_64BIT_MASK 0xffffffffffffffffULL u64 stream_dma_64bit_mask = DMA_64BIT_MASK ; and, just to complete the thought, we are call BOTH pci_set_dma_mask() and pci_set_consistent_dma_mask() ( in that order ) with the 32 bit dma mask as the input value. William, if I sent you a kernel patch could you test it? I'm writing code now and expect to have something ready tomorrow (Friday). P. I'm willing. I just have to wait my turn for the machine with 16gig of memory. Of course, we also have to have matching kernels... Created attachment 312159 [details] RHEL4 fix for this issue William, please test with this patch. It applies to the latest kernel source available from here: http://people.redhat.com/vgoyal/rhel4/ P. Created attachment 312162 [details]
Upstream patch that fixes an overflow bug
Sent to LKML and Jesse Barnes.
Created attachment 312163 [details]
Upstream patch that fixes alignment bug
Sent to LKML & Jesse Barnes.
Please clarify - which test do you wish me to execute ? Do you want me to exercise my original problem as described in comment #1, or am I to exercise the dma/pci pool stuff referenced in comment #122 ? Also, what is the relationship between this patch and bug report #454417 ? (In reply to comment #134) > > Please clarify - which test do you wish me to execute ? > > Do you want me to exercise my original problem as > described in comment #1, or am I to exercise the > dma/pci pool stuff referenced in comment #122 ? Actually I was hoping you could test my prarit.c module ... but now that I think of it, your independent driver test is probably better :) > > Also, what is the relationship between this patch and > bug report #454417 ? 454417 is for RHEL _5_. P. > > Also, what is the relationship between this patch and > bug report #454417 ? >454417 is for RHEL _5_. Oops. Scratch that. 454417 is probably no longer valid after this patch, IMO. An unintended consequence of fixing this code is that pci_alloc_consistent/dma_alloc_coherent will always return size-aligned values. P. I *finally* got the upstream patches through to LKML. Links to upstream submits for this issue: http://marc.info/?l=linux-kernel&m=121664984730778&w=2 http://marc.info/?l=linux-kernel&m=121664984830791&w=2 P. just for info, it looks like I will not be able to get time on the 16gig machine until Wed 7/23... William, no problem -- FYI, I've tested this on a few systems within RH and it seems to fix the issue. Before submitting to our internal kernel list, I would like to make sure it fixes your problem ;) and that there isn't another issue blocking you. P. Created attachment 312462 [details]
Upstream patch that fixes this issue
Submitted to LKML.
Patch upstream here: http://marc.info/?l=linux-kernel&m=121681201313560&w=2 P. Executive Summary - Success ! Details... using the "vanilla" kernel from comment #131, we saw that the problem described by this buzz report still existed. We used our own driver to reveal the problem. We did not use the test driver from comment #100. So, this kernel failed, as expected. . We then applied the patch ( also from comment #131 ) to the kernel. We executed the test using the same driver, and the test passed. thanks now the 64 million dollar question... When my customers ask "how do I get this patch? ", what do I tell them ? Something like, "For RedHat AS 4, you need patch such&such, which is available from Redhat via _____________ . " and "For RedHat AS 5, you need patch such&such, which is available from Redhat via _____________ . " For RHEL4 it looks likely that this will be in 4.8. I've opened up a separate BZ for RHEL5 -- 455813. P. Created attachment 312916 [details]
RHEL4 fix for this issue
Posted.
Updating PM score. Committed in 78.18.EL . RPMS are available at http://people.redhat.com/vgoyal/rhel4/ An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2009-1024.html |