Sorry for the repost, but I figured I might get the attention of someone
that has an IBM Thinkpad G41 with the updated subject.
--------------------------
Hi everyone,
I've been banging my head on this one a couple of days with no luck.
I have a IBM Thinkpad G41 with a pentium4M with Hyperthreading. I can't
get the PCMCIA working at all. I've tried turning off hyperthreading,
I've tried with and without preempt, I've even added pci=noacpi. I've
added Len's ACPI patches, but nothing works.
Here's lspci -vvv:
0000:00:00.0 Host bridge: Intel Corp. 82852/855GM Host Bridge (rev 02)
Subsystem: IBM: Unknown device 0579
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 d0000000 (32-bit, prefetchable) [size=256M]
Capabilities: <available only to root>
0000:00:00.1 System peripheral: Intel Corp. 855GM/GME GMCH Memory I/O Control Registers (rev 02)
Subsystem: IBM: Unknown device 057a
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
0000:00:00.3 System peripheral: Intel Corp. 855GM/GME GMCH Configuration Process Registers (rev 02)
Subsystem: IBM: Unknown device 057b
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
0000:00:01.0 PCI bridge: Intel Corp. 855GME GMCH Host-to-AGP Bridge (Virtual PCI-to-PCI) (rev 02) (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: 96
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: c1000000-c1ffffff
Prefetchable memory behind bridge: e0000000-efffffff
BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-
[ ... USB controllers snipped out ... ]
0000:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 81) (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=02, subordinate=08, sec-latency=168
I/O behind bridge: 00003000-00006fff
Memory behind bridge: c2000000-cfffffff
Prefetchable memory behind bridge: f0000000-f7ffffff
BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
0000:00:1f.0 ISA bridge: Intel Corp. 82801DBM LPC Interface Controller (rev 01)
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
[ ... snipped out IDE Bridge controllers too ... ]
0000:00:1f.3 SMBus: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 01)
Subsystem: IBM: Unknown device 0547
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 B routed to IRQ 11
Region 4: I/O ports at 1880 [size=32]
[ ... snipped audio VGA NVidia and Ethernet controllers ... ]
0000:02:01.0 CardBus bridge: Texas Instruments PCI1520 PC card Cardbus Controller (rev 01)
Subsystem: IBM ThinkPad T30/T40
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: 168, Cache Line Size: 0x20 (128 bytes)
Interrupt: pin A routed to IRQ 177
Region 0: Memory at 3fefb000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=02, secondary=03, subordinate=06, sec-latency=176
Memory window 0: 40000000-403ff000 (prefetchable)
Memory window 1: 40400000-407ff000
I/O window 0: 00004000-000040ff
I/O window 1: 00004400-000044ff
BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+
16-bit legacy interface ports at 0001
0000:02:01.1 CardBus bridge: Texas Instruments PCI1520 PC card Cardbus Controller (rev 01)
Subsystem: IBM ThinkPad T30/T40
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: 168, Cache Line Size: 0x20 (128 bytes)
Interrupt: pin B routed to IRQ 185
Region 0: Memory at 3fefc000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=02, secondary=07, subordinate=0a, sec-latency=176
Memory window 0: 40800000-40bff000 (prefetchable)
Memory window 1: 40c00000-40fff000
I/O window 0: 00004800-000048ff
I/O window 1: 00004c00-00004cff
BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt- PostWrite+
16-bit legacy interface ports at 0001
The above is probably more than anyone needs, but if I should show the
whole listing (USB, Audio and all), just let me know and I can post all
of it too.
And here's the dmesg:
Linux Kernel Card Services
options: [pci] [cardbus] [pm]
ACPI: PCI interrupt 0000:02:01.0[A] -> GSI 20 (level, low) -> IRQ 177
Yenta: CardBus bridge found at 0000:02:01.0 [1014:0512]
Yenta: Using INTVAL to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket 0000:02:01.0, mfunc 0x01001c22, devctl 0x64
Yenta TI: socket 0000:02:01.0 probing PCI interrupt failed, trying to fix
Yenta TI: socket 0000:02:01.0 no PCI interrupts. Fish. Please report.
Yenta: ISA IRQ mask 0x0000, PCI irq 0
Socket status: ffffffff
ACPI: PCI interrupt 0000:02:01.1[B] -> GSI 21 (level, low) -> IRQ 185
Yenta: CardBus bridge found at 0000:02:01.1 [1014:0512]
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket 0000:02:01.1, mfunc 0x01001c22, devctl 0x64
Yenta TI: socket 0000:02:01.1 probing PCI interrupt failed, trying to fix
Yenta TI: socket 0000:02:01.1 no PCI interrupts. Fish. Please report.
Yenta: ISA IRQ mask 0x0000, PCI irq 0
Socket status: 4410080c
(the above is from kernel.org 2.6.10 with Len's ACPI patches).
I've tried this with Debian stock kernels: 2.4.27-1-386, 2.6.8-2-686,
2.6.9-1-686, 2.6.10-1-686-smp
I've also tried kernel.org kernels with 2.6.9, 2.6.10 and
2.6.11-rc3-mm2. As I've mentioned, I've added Len's ACPI patches to
2.6.10 and still nothing works. I've tried disable_clkrun but still
nothing. I've found a couple of other patches on the net and nothing
works.
I've tried debugging this but PCMCIA is not my strong spot, so all I can
tell you is that the interrupt never comes in when Yenta probes it.
Does anyone else out there have a IBM Thinkpad G41 and have this
working? Or, do you have it and it is not working. I get no power to
the PCMCIA card slots, so they are basically useless now.
Any ideas would be appreciated.
Thanks,
-- Steve
On Sat, 19 Feb 2005, Steven Rostedt wrote:
>
> 0000:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 81) (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=02, subordinate=08, sec-latency=168
> I/O behind bridge: 00003000-00006fff
> Memory behind bridge: c2000000-cfffffff
> Prefetchable memory behind bridge: f0000000-f7ffffff
> BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
This is the bridge that your cardbus controller is behind:
> 0000:02:01.0 CardBus bridge: Texas Instruments PCI1520 PC card Cardbus Controller (rev 01)
> Subsystem: IBM ThinkPad T30/T40
> 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: 168, Cache Line Size: 0x20 (128 bytes)
> Interrupt: pin A routed to IRQ 177
> Region 0: Memory at 3fefb000 (32-bit, non-prefetchable) [size=4K]
> Bus: primary=02, secondary=03, subordinate=06, sec-latency=176
> Memory window 0: 40000000-403ff000 (prefetchable)
> Memory window 1: 40400000-407ff000
> I/O window 0: 00004000-000040ff
> I/O window 1: 00004400-000044ff
> BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+
> 16-bit legacy interface ports at 0001
>
> 0000:02:01.1 CardBus bridge: Texas Instruments PCI1520 PC card Cardbus Controller (rev 01)
> Subsystem: IBM ThinkPad T30/T40
> 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: 168, Cache Line Size: 0x20 (128 bytes)
> Interrupt: pin B routed to IRQ 185
> Region 0: Memory at 3fefc000 (32-bit, non-prefetchable) [size=4K]
> Bus: primary=02, secondary=07, subordinate=0a, sec-latency=176
> Memory window 0: 40800000-40bff000 (prefetchable)
> Memory window 1: 40c00000-40fff000
> I/O window 0: 00004800-000048ff
> I/O window 1: 00004c00-00004cff
> BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt- PostWrite+
> 16-bit legacy interface ports at 0001
And quite frankly, their "Region 0:" things look broken: the bridge is a
"Normal decode" bridge, which means that anything behind that bridge
should only map things _within_ the IO windows of the bridge, ie all IO
mappings on the cardbus bridge should be inside the IO mappings of the
parent bridge. But they aren't.
Now, your interrupts are a bit insane too, but they may actually be
correct for all I know. The Yenta code will just decide that interrupts
can't be working, since when it tries to trigger an interrupt it won't
come in: but that is quite possibly not due to broken interrupts, but
because the whole controller IO-MEM region has been mapped at the wrong
place, so the controller simply never _sees_ our writes.
The parent bridge has IO port mappings at 00003000-00006fff, and IO memory
mappings at c2000000-cfffffff and f0000000-f7ffffff. The cardbus stuff
_should_ all be behind those regions, but instead they are at 3fefb000 and
40000000-40fff000 (memory-mapped) and 00004000-00004cff (IO mapped).
So something is seriously broken.
That's a PCI layer brokenness, btw, not a PCMCIA brokenness.
Can you enable debugging in arch/i386/pci/pci.h and post the whole bootup
dmesg. Also, can you show what /proc/iomem looks like, and what
ls -R /sys/devices/pci*
says (that cardbus controller should be properly nested _inside_ that PCI
bridge, dammit!).
Greg, any ideas?
Linus
On Sat, 2005-02-19 at 16:59 -0800, Linus Torvalds wrote:
> The parent bridge has IO port mappings at 00003000-00006fff, and IO memory
> mappings at c2000000-cfffffff and f0000000-f7ffffff. The cardbus stuff
> _should_ all be behind those regions, but instead they are at 3fefb000 and
> 40000000-40fff000 (memory-mapped) and 00004000-00004cff (IO mapped).
>
Damn, I should have noticed that too, but I was so convinced that the
PCMCIA was broken (since that's usually what is) that I didn't look
elsewhere.
> So something is seriously broken.
>
> That's a PCI layer brokenness, btw, not a PCMCIA brokenness.
>
> Can you enable debugging in arch/i386/pci/pci.h and post the whole bootup
> dmesg. Also, can you show what /proc/iomem looks like, and what
> ls -R /sys/devices/pci*
>
Here's the scoop:
cat /proc/iomem:
00000000-0009efff : System RAM
0009f000-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000cfbff : Video ROM
000d0000-000d17ff : Adapter ROM
000d1800-000d27ff : Adapter ROM
000e0000-000effff : Extension ROM
000f0000-000fffff : System ROM
00100000-0f6effff : System RAM
00100000-00300976 : Kernel code
00300977-003d72ff : Kernel data
0f6f0000-0f6fffff : reserved
0f700000-3feeffff : System RAM
3fef0000-3fef7fff : ACPI Tables
3fef8000-3fef9fff : ACPI Non-volatile Storage
3fefa000-3fefa3ff : 0000:00:1f.1
3fefb000-3fefbfff : 0000:02:01.0
3fefb000-3fefbfff : yenta_socket
3fefc000-3fefcfff : 0000:02:01.1
3fefc000-3fefcfff : yenta_socket
3ff00000-3fffffff : reserved
40000000-403fffff : PCI CardBus #03
40400000-407fffff : PCI CardBus #03
40800000-40bfffff : PCI CardBus #07
40c00000-40ffffff : PCI CardBus #07
c0000000-c00003ff : 0000:00:1d.7
c0000000-c00003ff : ehci_hcd
c0000800-c00008ff : 0000:00:1f.5
c0000800-c00008ff : Intel 82801DB-ICH4
c0000c00-c0000dff : 0000:00:1f.5
c0000c00-c0000dff : Intel 82801DB-ICH4
c1000000-c1ffffff : PCI Bus #01
c1000000-c1ffffff : 0000:01:00.0
c1000000-c1ffffff : nvidia
c2000000-c200ffff : 0000:02:00.0
c2000000-c200ffff : tg3
c2010000-c201ffff : 0000:02:02.0
c2010000-c201ffff : ath
d0000000-dfffffff : 0000:00:00.0
e0000000-efffffff : PCI Bus #01
e0000000-efffffff : 0000:01:00.0
e0000000-e7ffffff : vesafb
fec00000-fec0ffff : reserved
fee00000-fee00fff : reserved
ff800000-ffffffff : reserved
============================================================
cat /proc/ioports
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-006f : keyboard
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0376-0376 : ide1
03bc-03be : parport0
03c0-03df : vesafb
03f6-03f6 : ide0
0cf8-0cff : PCI conf1
1000-107f : 0000:00:1f.0
1000-107f : motherboard
1000-1003 : PM1a_EVT_BLK
1004-1005 : PM1a_CNT_BLK
1008-100b : PM_TMR
1010-1015 : ACPI CPU throttle
1020-1020 : PM2_CNT_BLK
1028-102f : GPE0_BLK
1180-11bf : 0000:00:1f.0
1180-11bf : motherboard
1800-181f : 0000:00:1d.0
1800-181f : uhci_hcd
1820-183f : 0000:00:1d.1
1820-183f : uhci_hcd
1840-185f : 0000:00:1d.2
1840-185f : uhci_hcd
1860-186f : 0000:00:1f.1
1880-189f : 0000:00:1f.3
1880-188f : i801-smbus
18c0-18ff : 0000:00:1f.5
18c0-18ff : Intel 82801DB-ICH4
1c00-1cff : 0000:00:1f.5
1c00-1cff : Intel 82801DB-ICH4
2000-207f : 0000:00:1f.6
2000-207f : Intel 82801DB-ICH4 Modem
2400-24ff : 0000:00:1f.6
2400-24ff : Intel 82801DB-ICH4 Modem
4000-40ff : PCI CardBus #03
4400-44ff : PCI CardBus #03
4800-48ff : PCI CardBus #07
4c00-4cff : PCI CardBus #07
=======================================================
ls -R /sys/devices/pci*
/sys/devices/pci0000:00/:
0000:00:00.0
0000:00:00.1
0000:00:00.3
0000:00:01.0
0000:00:1d.0
0000:00:1d.1
0000:00:1d.2
0000:00:1d.7
0000:00:1e.0
0000:00:1f.0
0000:00:1f.1
0000:00:1f.3
0000:00:1f.5
0000:00:1f.6
detach_state
power
/sys/devices/pci0000:00/0000:00:00.0:
class
config
detach_state
device
driver
irq
local_cpus
power
resource
subsystem_device
subsystem_vendor
vendor
/sys/devices/pci0000:00/0000:00:00.0/power:
state
/sys/devices/pci0000:00/0000:00:00.1:
class
config
detach_state
device
irq
local_cpus
power
resource
subsystem_device
subsystem_vendor
vendor
/sys/devices/pci0000:00/0000:00:00.1/power:
state
/sys/devices/pci0000:00/0000:00:00.3:
class
config
detach_state
device
irq
local_cpus
power
resource
subsystem_device
subsystem_vendor
vendor
/sys/devices/pci0000:00/0000:00:00.3/power:
state
/sys/devices/pci0000:00/0000:00:01.0:
0000:01:00.0
class
config
detach_state
device
irq
local_cpus
power
resource
subsystem_device
subsystem_vendor
vendor
/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0:
class
config
detach_state
device
driver
irq
local_cpus
power
resource
rom
subsystem_device
subsystem_vendor
vendor
/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/power:
state
/sys/devices/pci0000:00/0000:00:01.0/power:
state
/sys/devices/pci0000:00/0000:00:1d.0:
class
config
detach_state
device
driver
irq
local_cpus
pools
power
resource
subsystem_device
subsystem_vendor
usb1
vendor
/sys/devices/pci0000:00/0000:00:1d.0/power:
state
/sys/devices/pci0000:00/0000:00:1d.0/usb1:
1-0:1.0
1-2
bcdDevice
bConfigurationValue
bDeviceClass
bDeviceProtocol
bDeviceSubClass
bmAttributes
bMaxPower
bNumConfigurations
bNumInterfaces
configuration
detach_state
devnum
driver
idProduct
idVendor
manufacturer
maxchild
power
product
serial
speed
version
/sys/devices/pci0000:00/0000:00:1d.0/usb1/1-0:1.0:
bAlternateSetting
bInterfaceClass
bInterfaceNumber
bInterfaceProtocol
bInterfaceSubClass
bNumEndpoints
detach_state
driver
power
/sys/devices/pci0000:00/0000:00:1d.0/usb1/1-0:1.0/power:
state
/sys/devices/pci0000:00/0000:00:1d.0/usb1/1-2:
1-2:1.0
bcdDevice
bConfigurationValue
bDeviceClass
bDeviceProtocol
bDeviceSubClass
bmAttributes
bMaxPower
bNumConfigurations
bNumInterfaces
configuration
detach_state
devnum
driver
idProduct
idVendor
manufacturer
maxchild
power
product
serial
speed
version
/sys/devices/pci0000:00/0000:00:1d.0/usb1/1-2/1-2:1.0:
bAlternateSetting
bInterfaceClass
bInterfaceNumber
bInterfaceProtocol
bInterfaceSubClass
bNumEndpoints
detach_state
driver
power
ttyUSB0
/sys/devices/pci0000:00/0000:00:1d.0/usb1/1-2/1-2:1.0/power:
state
/sys/devices/pci0000:00/0000:00:1d.0/usb1/1-2/1-2:1.0/ttyUSB0:
detach_state
driver
power
/sys/devices/pci0000:00/0000:00:1d.0/usb1/1-2/1-2:1.0/ttyUSB0/power:
state
/sys/devices/pci0000:00/0000:00:1d.0/usb1/1-2/power:
state
/sys/devices/pci0000:00/0000:00:1d.0/usb1/power:
state
/sys/devices/pci0000:00/0000:00:1d.1:
class
config
detach_state
device
driver
irq
local_cpus
pools
power
resource
subsystem_device
subsystem_vendor
usb2
vendor
/sys/devices/pci0000:00/0000:00:1d.1/power:
state
/sys/devices/pci0000:00/0000:00:1d.1/usb2:
2-0:1.0
bcdDevice
bConfigurationValue
bDeviceClass
bDeviceProtocol
bDeviceSubClass
bmAttributes
bMaxPower
bNumConfigurations
bNumInterfaces
configuration
detach_state
devnum
driver
idProduct
idVendor
manufacturer
maxchild
power
product
serial
speed
version
/sys/devices/pci0000:00/0000:00:1d.1/usb2/2-0:1.0:
bAlternateSetting
bInterfaceClass
bInterfaceNumber
bInterfaceProtocol
bInterfaceSubClass
bNumEndpoints
detach_state
driver
power
/sys/devices/pci0000:00/0000:00:1d.1/usb2/2-0:1.0/power:
state
/sys/devices/pci0000:00/0000:00:1d.1/usb2/power:
state
/sys/devices/pci0000:00/0000:00:1d.2:
class
config
detach_state
device
driver
irq
local_cpus
pools
power
resource
subsystem_device
subsystem_vendor
usb3
vendor
/sys/devices/pci0000:00/0000:00:1d.2/power:
state
/sys/devices/pci0000:00/0000:00:1d.2/usb3:
3-0:1.0
bcdDevice
bConfigurationValue
bDeviceClass
bDeviceProtocol
bDeviceSubClass
bmAttributes
bMaxPower
bNumConfigurations
bNumInterfaces
configuration
detach_state
devnum
driver
idProduct
idVendor
manufacturer
maxchild
power
product
serial
speed
version
/sys/devices/pci0000:00/0000:00:1d.2/usb3/3-0:1.0:
bAlternateSetting
bInterfaceClass
bInterfaceNumber
bInterfaceProtocol
bInterfaceSubClass
bNumEndpoints
detach_state
driver
power
/sys/devices/pci0000:00/0000:00:1d.2/usb3/3-0:1.0/power:
state
/sys/devices/pci0000:00/0000:00:1d.2/usb3/power:
state
/sys/devices/pci0000:00/0000:00:1d.7:
class
config
detach_state
device
driver
irq
local_cpus
pools
power
resource
subsystem_device
subsystem_vendor
usb4
vendor
/sys/devices/pci0000:00/0000:00:1d.7/power:
state
/sys/devices/pci0000:00/0000:00:1d.7/usb4:
4-0:1.0
bcdDevice
bConfigurationValue
bDeviceClass
bDeviceProtocol
bDeviceSubClass
bmAttributes
bMaxPower
bNumConfigurations
bNumInterfaces
configuration
detach_state
devnum
driver
idProduct
idVendor
manufacturer
maxchild
power
product
serial
speed
version
/sys/devices/pci0000:00/0000:00:1d.7/usb4/4-0:1.0:
bAlternateSetting
bInterfaceClass
bInterfaceNumber
bInterfaceProtocol
bInterfaceSubClass
bNumEndpoints
detach_state
driver
power
/sys/devices/pci0000:00/0000:00:1d.7/usb4/4-0:1.0/power:
state
/sys/devices/pci0000:00/0000:00:1d.7/usb4/power:
state
/sys/devices/pci0000:00/0000:00:1e.0:
0000:02:00.0
0000:02:01.0
0000:02:01.1
0000:02:02.0
class
config
detach_state
device
irq
local_cpus
power
resource
subsystem_device
subsystem_vendor
vendor
/sys/devices/pci0000:00/0000:00:1e.0/0000:02:00.0:
class
config
detach_state
device
driver
irq
local_cpus
power
resource
subsystem_device
subsystem_vendor
vendor
/sys/devices/pci0000:00/0000:00:1e.0/0000:02:00.0/power:
state
/sys/devices/pci0000:00/0000:00:1e.0/0000:02:01.0:
class
config
detach_state
device
driver
irq
local_cpus
power
resource
subsystem_device
subsystem_vendor
vendor
/sys/devices/pci0000:00/0000:00:1e.0/0000:02:01.0/power:
state
/sys/devices/pci0000:00/0000:00:1e.0/0000:02:01.1:
class
config
detach_state
device
driver
irq
local_cpus
power
resource
subsystem_device
subsystem_vendor
vendor
/sys/devices/pci0000:00/0000:00:1e.0/0000:02:01.1/power:
state
/sys/devices/pci0000:00/0000:00:1e.0/0000:02:02.0:
class
config
detach_state
device
driver
irq
local_cpus
power
resource
subsystem_device
subsystem_vendor
vendor
/sys/devices/pci0000:00/0000:00:1e.0/0000:02:02.0/power:
state
/sys/devices/pci0000:00/0000:00:1e.0/power:
state
/sys/devices/pci0000:00/0000:00:1f.0:
class
config
detach_state
device
irq
local_cpus
power
resource
subsystem_device
subsystem_vendor
vendor
/sys/devices/pci0000:00/0000:00:1f.0/power:
state
/sys/devices/pci0000:00/0000:00:1f.1:
class
config
detach_state
device
driver
irq
local_cpus
power
resource
subsystem_device
subsystem_vendor
vendor
/sys/devices/pci0000:00/0000:00:1f.1/power:
state
/sys/devices/pci0000:00/0000:00:1f.3:
class
config
detach_state
device
driver
i2c-0
irq
local_cpus
power
resource
subsystem_device
subsystem_vendor
vendor
/sys/devices/pci0000:00/0000:00:1f.3/i2c-0:
detach_state
name
power
/sys/devices/pci0000:00/0000:00:1f.3/i2c-0/power:
state
/sys/devices/pci0000:00/0000:00:1f.3/power:
state
/sys/devices/pci0000:00/0000:00:1f.5:
class
config
detach_state
device
driver
irq
local_cpus
power
resource
subsystem_device
subsystem_vendor
vendor
/sys/devices/pci0000:00/0000:00:1f.5/power:
state
/sys/devices/pci0000:00/0000:00:1f.6:
class
config
detach_state
device
driver
irq
local_cpus
power
resource
subsystem_device
subsystem_vendor
vendor
/sys/devices/pci0000:00/0000:00:1f.6/power:
state
/sys/devices/pci0000:00/power:
state
==============================================================
dmesg is attached.
Thanks,
-- Steve
On Sat, 19 Feb 2005, Steven Rostedt wrote:
>
> Here's the scoop:
>
> cat /proc/iomem:
Ok. This one does not show device 00:1e.0 _at_all_. It had:
I/O behind bridge: 00003000-00006fff
Memory behind bridge: c2000000-cfffffff
Prefetchable memory behind bridge: f0000000-f7ffffff
and it just doesn't show. It shows some of the devices that are behind
that bridge, though, and it should PCI Bus #01. Why not #02? Looks like we
must have decided that that PCI bus is transparent.
But we have the PCI device hierarchy right:
> /sys/devices/pci0000:00/0000:00:1e.0/0000:02:00.0:
> /sys/devices/pci0000:00/0000:00:1e.0/0000:02:01.0:
> /sys/devices/pci0000:00/0000:00:1e.0/0000:02:01.1:
> /sys/devices/pci0000:00/0000:00:1e.0/0000:02:02.0:
Oh, and your dmesg does show:
PCI: Transparent bridge - 0000:00:1e.0
so that explains it. We believe that 0:1e.0 is transparent.
Maybe we're even right. We do have a few quirky bridges that are marked
transparent. I didn't think yours was one of them, though.
I _think_ it's the code in arch/i386/pci/fixup.c that does this. See the
static void __devinit pci_fixup_transparent_bridge(struct pci_dev *dev)
thing, and try to disable it. Maybe that rule is wrong, and triggers much
too often?
Or maybe it really _is_ a transparent bridge after all, and the problem is
somewhere else. Disabling the pci_fixup_transparent_bridge logic is a good
thing to try first, though.
Linus
On Sat, 2005-02-19 at 18:10 -0800, Linus Torvalds wrote:
> I _think_ it's the code in arch/i386/pci/fixup.c that does this. See the
>
> static void __devinit pci_fixup_transparent_bridge(struct pci_dev *dev)
>
> thing, and try to disable it. Maybe that rule is wrong, and triggers much
> too often?
>
Linus,
Thank you very much! That was it. The following patch made everything
look good.
--- arch/i386/pci/fixup.c.orig 2005-02-19 22:22:29.622416639 -0500
+++ arch/i386/pci/fixup.c 2005-02-19 22:20:39.562713691 -0500
@@ -208,7 +208,9 @@
static void __devinit pci_fixup_transparent_bridge(struct pci_dev *dev)
{
if ((dev->class >> 8) == PCI_CLASS_BRIDGE_PCI &&
- (dev->device & 0xff00) == 0x2400)
+ (dev->device & 0xff00) == 0x2400 &&
+ /* the 2448 bridge is not transparent */
+ dev->device != 0x2448)
dev->transparent = 1;
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_ANY_ID, pci_fixup_transparent_bridge);
PCMCIA cards now show up. Although I still have yet to get one of mine
working, but that's because of the card and not the bridge. Now I need
to start downloading drivers for my card. But at least the kernel now
sees them!
Thanks again,
-- Steve
On Sat, 19 Feb 2005, Steven Rostedt wrote:
>
> On Sat, 2005-02-19 at 18:10 -0800, Linus Torvalds wrote:
>
> > I _think_ it's the code in arch/i386/pci/fixup.c that does this. See the
> >
> > static void __devinit pci_fixup_transparent_bridge(struct pci_dev *dev)
> >
> > thing, and try to disable it. Maybe that rule is wrong, and triggers much
> > too often?
> >
>
> Linus,
>
> Thank you very much! That was it. The following patch made everything
> look good.
Ok. I've fired off an email to some Intel people asking what the
real rules are wrt Intel PCI-PCI bridges. It may be that it's not that
particular chip, but some generic rule (like "all Intel bridges act like
they are subtractive decode _except_ if they actually have the IO
start/stop ranges set" or something like that).
If anybody on the list can figure the Intel bridge decoding rules out,
please holler..
Linus
On Sat, 19 Feb 2005, Steven Rostedt wrote:
>
> + /* the 2448 bridge is not transparent */
> + dev->device != 0x2448)
Btw, I've got a laptop with the exact same bridge chip PCI ID (well, mine
is "rev 83", while yours claims to be "rev 81"), and mine definitely _is_
transparent.
On my machine, "lspci -vvn -s 0:1e.0" gives:
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: 90000000-901fffff
Prefetchable memory behind bridge: fff00000-000fffff
ie the IO and prefetchable memory ranges have actually been _disabled_
(that is, if we actually care about the PCI specs), yet it definitely
forwards them.
It looks to me like the Intel bridges have this magic behaviour where if
you disable a range, it turns into a subtractive decode.
Now, that's not hard to handle, and in fact, making the PCI bridge
handling in Linux match that kind of behaviour actually simplifies some
code.
Does a patch like this (instead of your version) work for you? It removes
the Intel quirk entirely, and replaces it with the "if there's no
resource, use the parent resource as the default fallback" code.
This seems to work on my laptop, which has the "transparent" case
(actually, it's "interesting" on my laptop, since it's only
half-transparent after this change: the non-prefetchable range is now put
in the 0x90000000 area).
Does it work for the non-transparent case too? It should, but..
Damn. I think this might be the right thing to do, but I also suspect it's
not worth doing for 2.6.11, if only because it needs more testing. In
particular, the partial transparency case is a bit unnerving.
Linus
----
===== arch/i386/pci/fixup.c 1.24 vs edited =====
--- 1.24/arch/i386/pci/fixup.c 2005-01-11 16:42:41 -08:00
+++ edited/arch/i386/pci/fixup.c 2005-02-19 22:21:42 -08:00
@@ -197,23 +197,6 @@
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8367_0, pci_fixup_via_northbridge_bug);
/*
- * For some reasons Intel decided that certain parts of their
- * 815, 845 and some other chipsets must look like PCI-to-PCI bridges
- * while they are obviously not. The 82801 family (AA, AB, BAM/CAM,
- * BA/CA/DB and E) PCI bridges are actually HUB-to-PCI ones, according
- * to Intel terminology. These devices do forward all addresses from
- * system to PCI bus no matter what are their window settings, so they are
- * "transparent" (or subtractive decoding) from programmers point of view.
- */
-static void __devinit pci_fixup_transparent_bridge(struct pci_dev *dev)
-{
- if ((dev->class >> 8) == PCI_CLASS_BRIDGE_PCI &&
- (dev->device & 0xff00) == 0x2400)
- dev->transparent = 1;
-}
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_ANY_ID, pci_fixup_transparent_bridge);
-
-/*
* Fixup for C1 Halt Disconnect problem on nForce2 systems.
*
* From information provided by "Allen Martin" <[email protected]>:
===== drivers/pci/probe.c 1.78 vs edited =====
--- 1.78/drivers/pci/probe.c 2005-02-02 22:42:24 -08:00
+++ edited/drivers/pci/probe.c 2005-02-19 22:16:33 -08:00
@@ -241,17 +241,20 @@
if (!dev) /* It's a host bus, nothing to read */
return;
+ /*
+ * We default to the parent resources, and override them only
+ * if this device has its own range defined.
+ */
+ for(i = 0; i < PCI_BUS_NUM_RESOURCES; i++)
+ child->resource[i] = child->parent->resource[i];
+
if (dev->transparent) {
printk(KERN_INFO "PCI: Transparent bridge - %s\n", pci_name(dev));
- for(i = 0; i < PCI_BUS_NUM_RESOURCES; i++)
- child->resource[i] = child->parent->resource[i];
return;
}
- for(i=0; i<3; i++)
- child->resource[i] = &dev->resource[PCI_BRIDGE_RESOURCES+i];
-
- res = child->resource[0];
+ /* Resource 0 - IO ports */
+ res = &dev->resource[PCI_BRIDGE_RESOURCES+0];
pci_read_config_byte(dev, PCI_IO_BASE, &io_base_lo);
pci_read_config_byte(dev, PCI_IO_LIMIT, &io_limit_lo);
base = (io_base_lo & PCI_IO_RANGE_MASK) << 8;
@@ -269,9 +272,11 @@
res->flags = (io_base_lo & PCI_IO_RANGE_TYPE_MASK) | IORESOURCE_IO;
res->start = base;
res->end = limit + 0xfff;
+ child->resource[0] = res;
}
- res = child->resource[1];
+ /* Resource 1 - nonprefetchable memory resource */
+ res = &dev->resource[PCI_BRIDGE_RESOURCES+1];
pci_read_config_word(dev, PCI_MEMORY_BASE, &mem_base_lo);
pci_read_config_word(dev, PCI_MEMORY_LIMIT, &mem_limit_lo);
base = (mem_base_lo & PCI_MEMORY_RANGE_MASK) << 16;
@@ -280,9 +285,11 @@
res->flags = (mem_base_lo & PCI_MEMORY_RANGE_TYPE_MASK) | IORESOURCE_MEM;
res->start = base;
res->end = limit + 0xfffff;
+ child->resource[1] = res;
}
- res = child->resource[2];
+ /* Resource 2 - prefetchable memory resource */
+ res = &dev->resource[PCI_BRIDGE_RESOURCES+2];
pci_read_config_word(dev, PCI_PREF_MEMORY_BASE, &mem_base_lo);
pci_read_config_word(dev, PCI_PREF_MEMORY_LIMIT, &mem_limit_lo);
base = (mem_base_lo & PCI_PREF_RANGE_MASK) << 16;
@@ -314,6 +321,7 @@
res->flags = (mem_base_lo & PCI_MEMORY_RANGE_TYPE_MASK) | IORESOURCE_MEM | IORESOURCE_PREFETCH;
res->start = base;
res->end = limit + 0xfffff;
+ child->resource[2] = res;
}
}
On Sat, 19 Feb 2005, Linus Torvalds wrote:
>
> Does a patch like this (instead of your version) work for you? It removes
> the Intel quirk entirely, and replaces it with the "if there's no
> resource, use the parent resource as the default fallback" code.
Here's a very very slightly changed patch. The only addition is to make
the extra line of
b->resource[2] = &iomem_resource;
which makes the root PCI device have "iomem_resource" for both it's
prefetchable and non-prefetchable resource. That's damn subtle, but it
means that it the non-prefetchable one is overridden by a half-transparent
setup like I have, then in order to see a prefetchable area at all, you
want that root iomem_resource to "shine through" the transparent
prefetchable region.
Andrew, I think this should be tested in -mm. I think it will fix Stevens
laptop, and the more I think about it, the more convinced I am that is it
the RightThing to do.. But it could easily break something subtle.
Linus
----
===== arch/i386/pci/fixup.c 1.24 vs edited =====
--- 1.24/arch/i386/pci/fixup.c 2005-01-11 16:42:41 -08:00
+++ edited/arch/i386/pci/fixup.c 2005-02-19 22:21:42 -08:00
@@ -197,23 +197,6 @@
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8367_0, pci_fixup_via_northbridge_bug);
/*
- * For some reasons Intel decided that certain parts of their
- * 815, 845 and some other chipsets must look like PCI-to-PCI bridges
- * while they are obviously not. The 82801 family (AA, AB, BAM/CAM,
- * BA/CA/DB and E) PCI bridges are actually HUB-to-PCI ones, according
- * to Intel terminology. These devices do forward all addresses from
- * system to PCI bus no matter what are their window settings, so they are
- * "transparent" (or subtractive decoding) from programmers point of view.
- */
-static void __devinit pci_fixup_transparent_bridge(struct pci_dev *dev)
-{
- if ((dev->class >> 8) == PCI_CLASS_BRIDGE_PCI &&
- (dev->device & 0xff00) == 0x2400)
- dev->transparent = 1;
-}
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_ANY_ID, pci_fixup_transparent_bridge);
-
-/*
* Fixup for C1 Halt Disconnect problem on nForce2 systems.
*
* From information provided by "Allen Martin" <[email protected]>:
===== drivers/pci/probe.c 1.78 vs edited =====
--- 1.78/drivers/pci/probe.c 2005-02-02 22:42:24 -08:00
+++ edited/drivers/pci/probe.c 2005-02-19 22:44:24 -08:00
@@ -241,17 +241,20 @@
if (!dev) /* It's a host bus, nothing to read */
return;
+ /*
+ * We default to the parent resources, and override them only
+ * if this device has its own range defined.
+ */
+ for(i = 0; i < PCI_BUS_NUM_RESOURCES; i++)
+ child->resource[i] = child->parent->resource[i];
+
if (dev->transparent) {
printk(KERN_INFO "PCI: Transparent bridge - %s\n", pci_name(dev));
- for(i = 0; i < PCI_BUS_NUM_RESOURCES; i++)
- child->resource[i] = child->parent->resource[i];
return;
}
- for(i=0; i<3; i++)
- child->resource[i] = &dev->resource[PCI_BRIDGE_RESOURCES+i];
-
- res = child->resource[0];
+ /* Resource 0 - IO ports */
+ res = &dev->resource[PCI_BRIDGE_RESOURCES+0];
pci_read_config_byte(dev, PCI_IO_BASE, &io_base_lo);
pci_read_config_byte(dev, PCI_IO_LIMIT, &io_limit_lo);
base = (io_base_lo & PCI_IO_RANGE_MASK) << 8;
@@ -269,9 +272,11 @@
res->flags = (io_base_lo & PCI_IO_RANGE_TYPE_MASK) | IORESOURCE_IO;
res->start = base;
res->end = limit + 0xfff;
+ child->resource[0] = res;
}
- res = child->resource[1];
+ /* Resource 1 - nonprefetchable memory resource */
+ res = &dev->resource[PCI_BRIDGE_RESOURCES+1];
pci_read_config_word(dev, PCI_MEMORY_BASE, &mem_base_lo);
pci_read_config_word(dev, PCI_MEMORY_LIMIT, &mem_limit_lo);
base = (mem_base_lo & PCI_MEMORY_RANGE_MASK) << 16;
@@ -280,9 +285,11 @@
res->flags = (mem_base_lo & PCI_MEMORY_RANGE_TYPE_MASK) | IORESOURCE_MEM;
res->start = base;
res->end = limit + 0xfffff;
+ child->resource[1] = res;
}
- res = child->resource[2];
+ /* Resource 2 - prefetchable memory resource */
+ res = &dev->resource[PCI_BRIDGE_RESOURCES+2];
pci_read_config_word(dev, PCI_PREF_MEMORY_BASE, &mem_base_lo);
pci_read_config_word(dev, PCI_PREF_MEMORY_LIMIT, &mem_limit_lo);
base = (mem_base_lo & PCI_PREF_RANGE_MASK) << 16;
@@ -314,6 +321,7 @@
res->flags = (mem_base_lo & PCI_MEMORY_RANGE_TYPE_MASK) | IORESOURCE_MEM | IORESOURCE_PREFETCH;
res->start = base;
res->end = limit + 0xfffff;
+ child->resource[2] = res;
}
}
@@ -912,6 +920,7 @@
b->number = b->secondary = bus;
b->resource[0] = &ioport_resource;
b->resource[1] = &iomem_resource;
+ b->resource[2] = &iomem_resource;
b->subordinate = pci_scan_child_bus(b);
On Sat, Feb 19, 2005 at 08:36:12PM -0500, Steven Rostedt wrote:
> Linux version 2.6.10 (root@bilbo) (gcc version 3.3.5 (Debian 1:3.3.5-8)) #13 SMP Sat Feb 19 20:12:19 EST 2005
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 000000000009f000 (usable)
> BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved)
> BIOS-e820: 00000000000d0000 - 00000000000d4000 (reserved)
> BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 000000000f6f0000 (usable)
> BIOS-e820: 000000000f6f0000 - 000000000f700000 (reserved)
> BIOS-e820: 000000000f700000 - 000000003fef0000 (usable)
> BIOS-e820: 000000003fef0000 - 000000003fef8000 (ACPI data)
> BIOS-e820: 000000003fef8000 - 000000003fefa000 (ACPI NVS)
> BIOS-e820: 000000003ff00000 - 0000000040000000 (reserved)
Your BIOS is broken. You probably have 1GB of RAM which extends from
0x00000000 to 0x40000000. However, there's a hole in the ACPI map
between 0x3fefa000 and 0x3ff00000. This is where your Cardbus devices
are ending up:
> 3fefa000-3fefa3ff : 0000:00:1f.1
> 3fefb000-3fefbfff : 0000:02:01.0
> 3fefb000-3fefbfff : yenta_socket
> 3fefc000-3fefcfff : 0000:02:01.1
> 3fefc000-3fefcfff : yenta_socket
Changing the bridge type to non-transparent just means that we find
we can't allocate the bridge resources in this small window, so they
get moved elsewhere.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On Sun, Feb 20, 2005 at 08:22:26AM +0000, Russell King wrote:
> On Sat, Feb 19, 2005 at 08:36:12PM -0500, Steven Rostedt wrote:
> > Linux version 2.6.10 (root@bilbo) (gcc version 3.3.5 (Debian 1:3.3.5-8)) #13 SMP Sat Feb 19 20:12:19 EST 2005
> > BIOS-provided physical RAM map:
> > BIOS-e820: 0000000000000000 - 000000000009f000 (usable)
> > BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved)
> > BIOS-e820: 00000000000d0000 - 00000000000d4000 (reserved)
> > BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
> > BIOS-e820: 0000000000100000 - 000000000f6f0000 (usable)
> > BIOS-e820: 000000000f6f0000 - 000000000f700000 (reserved)
> > BIOS-e820: 000000000f700000 - 000000003fef0000 (usable)
> > BIOS-e820: 000000003fef0000 - 000000003fef8000 (ACPI data)
> > BIOS-e820: 000000003fef8000 - 000000003fefa000 (ACPI NVS)
> > BIOS-e820: 000000003ff00000 - 0000000040000000 (reserved)
>
> Your BIOS is broken. You probably have 1GB of RAM which extends from
> 0x00000000 to 0x40000000. However, there's a hole in the ACPI map
> between 0x3fefa000 and 0x3ff00000.
BTW, try passing:
reserve=0x3fefa000,0x6000
to the kernel - this will mark the "hole" reserved and should reallocate
the resources which are clashing with the RAM.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On Sat, 2005-02-19 at 22:51 -0800, Linus Torvalds wrote:
> Does a patch like this (instead of your version) work for you? It removes
> the Intel quirk entirely, and replaces it with the "if there's no
> resource, use the parent resource as the default fallback" code.
Hi Linus,
I live on the East coast so it's later for me than for you, so sorry
about not responding earlier. I have to go to my daughter's gymnastics
meet today so I probably won't get to try any of this till tomorrow.
Thanks,
-- Steve
On Sun, 2005-02-20 at 08:22 +0000, Russell King wrote:
> Your BIOS is broken. You probably have 1GB of RAM which extends from
> 0x00000000 to 0x40000000.
Just to leave no doubt. Yes, I have a Gig of RAM.
-- Steve
On Sun, 2005-02-20 at 10:20 +0000, Russell King wrote:
> BTW, try passing:
>
> reserve=0x3fefa000,0x6000
>
> to the kernel - this will mark the "hole" reserved and should reallocate
> the resources which are clashing with the RAM.
>
I just tried this on 2.6.9 (with no patches) and it worked. So I think
Russ is right.
I guess the problem arises when you have an IBM G41 Thinkpad with a Gig
of RAM.
Linus,
How much RAM is on your machine?
-- Steve
On Sun, 20 Feb 2005, Russell King wrote:
> On Sat, Feb 19, 2005 at 08:36:12PM -0500, Steven Rostedt wrote:
> > BIOS-e820: 0000000000000000 - 000000000009f000 (usable)
> > BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved)
> > BIOS-e820: 00000000000d0000 - 00000000000d4000 (reserved)
> > BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
> > BIOS-e820: 0000000000100000 - 000000000f6f0000 (usable)
> > BIOS-e820: 000000000f6f0000 - 000000000f700000 (reserved)
> > BIOS-e820: 000000000f700000 - 000000003fef0000 (usable)
> > BIOS-e820: 000000003fef0000 - 000000003fef8000 (ACPI data)
> > BIOS-e820: 000000003fef8000 - 000000003fefa000 (ACPI NVS)
> > BIOS-e820: 000000003ff00000 - 0000000040000000 (reserved)
>
> Your BIOS is broken. You probably have 1GB of RAM which extends from
> 0x00000000 to 0x40000000. However, there's a hole in the ACPI map
> between 0x3fefa000 and 0x3ff00000.
Good point. And dammit, we've had that problem too many times before.
And I think the reason for that bug is that we use "max_low_pfn" to
determine where we should start allocating PCI memory. We actually round
it up to the next megabyte, which _should_ have made us not allocate in
that small region (the last usable page is 0x3fef0000, rounded up to the
nearest megabyte is 0x3ff00000, which is marked as "reserved", so we
_should_ have allocated above that quite nicely).
However, we are screwed by the fact that "max_low_pfn" is actually limited
by MAXMEM_PFN, which is the kernel _mappable_ memory, so MAXMEM is
actually much less than one megabyte (it's one megabyte minus
"VMALLOC_RESERVE", which defaults to 128MB).
But the PCI allocations are not at all limited by MAXMEM - they want to be
in the low 4GB, but that's the only real limit. So using "max_low_pfn" to
determine where to start PCI allocations is pretty bogus.
I'll try to write something that actually looks at the e820 memory map
properly.
Linus
On Sun, 20 Feb 2005, Linus Torvalds wrote:
>
> But the PCI allocations are not at all limited by MAXMEM - they want to be
> in the low 4GB, but that's the only real limit. So using "max_low_pfn" to
> determine where to start PCI allocations is pretty bogus.
>
> I'll try to write something that actually looks at the e820 memory map
> properly.
Russell, what do your eagle-eyes think of a patch like this?
Steven, does this fix it without the need for any kernel command line (or
any other patches, for that matter - ie revert all the transparency-
changing ones)?
Linus
----
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/02/20 09:43:19-08:00 [email protected]
# Use e820 memory map to determine PCI allocation area.
#
# Don't use the VM numbers (max_low_pfn and friends), since they depend
# on the partial kernel linear mapping and only partially on the actual
# physical memory layout.
#
# arch/i386/kernel/setup.c
# 2005/02/20 09:43:12-08:00 [email protected] +19 -6
# Use e820 memory map to determine PCI allocation area.
#
# Don't use the VM numbers (max_low_pfn and friends), since they depend
# on the partial kernel linear mapping and only partially on the actual
# physical memory layout.
#
diff -Nru a/arch/i386/kernel/setup.c b/arch/i386/kernel/setup.c
--- a/arch/i386/kernel/setup.c 2005-02-20 09:54:35 -08:00
+++ b/arch/i386/kernel/setup.c 2005-02-20 09:54:35 -08:00
@@ -1166,9 +1166,10 @@
/*
* Request address space for all standard resources
*/
-static void __init register_memory(unsigned long max_low_pfn)
+static void __init register_memory(void)
{
- unsigned long low_mem_size;
+ long long gapsize;
+ unsigned long long last;
int i;
if (efi_enabled)
@@ -1184,9 +1185,21 @@
request_resource(&ioport_resource, &standard_io_resources[i]);
/* Tell the PCI layer not to allocate too close to the RAM area.. */
- low_mem_size = ((max_low_pfn << PAGE_SHIFT) + 0xfffff) & ~0xfffff;
- if (low_mem_size > pci_mem_start)
- pci_mem_start = low_mem_size;
+ last = 0x100000000ull;
+ gapsize = 0x400000;
+ i = e820.nr_map;
+ while (--i >= 0) {
+ unsigned long long start = e820.map[i].addr;
+ unsigned long long end = start + e820.map[i].size;
+ long long gap = last - end;
+
+ if (gap > gapsize) {
+ gapsize = gap;
+ pci_mem_start = ((unsigned long) end + 0xfffff) & ~0xfffff;
+ }
+ last = start;
+ }
+ printk("Allocating PCI resources starting at %08lx\n", pci_mem_start);
}
/* Use inline assembly to define this because the nops are defined
@@ -1432,7 +1445,7 @@
get_smp_config();
#endif
- register_memory(max_low_pfn);
+ register_memory();
#ifdef CONFIG_VT
#if defined(CONFIG_VGA_CONSOLE)
On Sun, 20 Feb 2005, Linus Torvalds wrote:
>Russell, what do your eagle-eyes think of a patch like this?
>
>Steven, does this fix it without the need for any kernel command line (or
>any other patches, for that matter - ie revert all the transparency-
>changing ones)?
>
> Linus
I tried the patch on my G40 with 1Gb RAM (previous thread about it is at
http://marc.theaimsgroup.com/?t=110889153400001&r=1&w=2), and it works
great, PCI resources are now located at 0x40000000 and no further
tricks/patches are necessary.
Re,
David
On Sun, 2005-02-20 at 09:56 -0800, Linus Torvalds wrote:
> Steven, does this fix it without the need for any kernel command line (or
> any other patches, for that matter - ie revert all the transparency-
> changing ones)?
>
> Linus
>
Hi Linus,
I just tried it out (after removing all my crap) and yes it works.
Thanks,
-- Steve
On Sat, 2005-02-19 at 20:02 -0800, Linus Torvalds wrote:
>
> On Sat, 19 Feb 2005, Steven Rostedt wrote:
> >
> > On Sat, 2005-02-19 at 18:10 -0800, Linus Torvalds wrote:
> >
> > > I _think_ it's the code in arch/i386/pci/fixup.c that does this. See the
> > >
> > > static void __devinit pci_fixup_transparent_bridge(struct pci_dev *dev)
> > >
> > > thing, and try to disable it. Maybe that rule is wrong, and triggers much
> > > too often?
> > >
> >
> > Linus,
> >
> > Thank you very much! That was it. The following patch made everything
> > look good.
>
> Ok. I've fired off an email to some Intel people asking what the
> real rules are wrt Intel PCI-PCI bridges. It may be that it's not that
> particular chip, but some generic rule (like "all Intel bridges act like
> they are subtractive decode _except_ if they actually have the IO
> start/stop ranges set" or something like that).
>
> If anybody on the list can figure the Intel bridge decoding rules out,
> please holler..
>
> Linus
Actually, I've ran into a similar situation on my hardware. After
looking into it for a while, I'm pretty sure it's actually a transparent
bridge (despite it not indicating such in the programing interface class
code). Have you heard anything more?
Thanks,
Adam
On Sun, 2005-02-20 at 09:23 -0800, Linus Torvalds wrote:
>
> On Sun, 20 Feb 2005, Russell King wrote:
> > On Sat, Feb 19, 2005 at 08:36:12PM -0500, Steven Rostedt wrote:
> > > BIOS-e820: 0000000000000000 - 000000000009f000 (usable)
> > > BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved)
> > > BIOS-e820: 00000000000d0000 - 00000000000d4000 (reserved)
> > > BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
> > > BIOS-e820: 0000000000100000 - 000000000f6f0000 (usable)
> > > BIOS-e820: 000000000f6f0000 - 000000000f700000 (reserved)
> > > BIOS-e820: 000000000f700000 - 000000003fef0000 (usable)
> > > BIOS-e820: 000000003fef0000 - 000000003fef8000 (ACPI data)
> > > BIOS-e820: 000000003fef8000 - 000000003fefa000 (ACPI NVS)
> > > BIOS-e820: 000000003ff00000 - 0000000040000000 (reserved)
> >
> > Your BIOS is broken. You probably have 1GB of RAM which extends from
> > 0x00000000 to 0x40000000. However, there's a hole in the ACPI map
> > between 0x3fefa000 and 0x3ff00000.
>
> Good point. And dammit, we've had that problem too many times before.
ACPI will report the ranges available to a PCI root bridge, even on
single root machines. I'm hoping to take advantage of this in my PCI
bus changes. It should help with these sort of problems.
Thanks,
Adam