* pata_sl82c105 can not reserve IO region
@ 2006-11-30 16:52 Olaf Hering
2006-11-30 17:10 ` Alan
` (3 more replies)
0 siblings, 4 replies; 95+ messages in thread
From: Olaf Hering @ 2006-11-30 16:52 UTC (permalink / raw)
To: linux-ide, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 459 bytes --]
pata_sl82c105 can be used on the ppc64 POWER4 system p610, p615 and p630
for the onboard IDE CD drive. It could be also used for ppc32 Motorola
PowerStack PReP systems.
Unfortunately, it doesnt work for me on the p630:
PCI: Enabling device: (0000:00:03.1), cmd 141
PCI: Unable to reserve I/O region #6:10@0 for device 0000:00:03.1
pata_sl82c105: probe of 0000:00:03.1 failed with error -16
Any idea how to fix it properly?
dmesg and other info attached.
[-- Attachment #2: winbond-ide.txt --]
[-- Type: text/plain, Size: 31537 bytes --]
Using pSeries machine description
Page orders: linear mapping = 24, virtual = 12, io = 12
Found legacy serial port 0 for /pci@400000000110/isa@3/serial@i3f8
port=3f8, taddr=3fd300003f8, irq=0, clk=1843200, speed=0
Found legacy serial port 1 for /pci@400000000110/isa@3/serial@i2f8
port=2f8, taddr=3fd300002f8, irq=0, clk=1843200, speed=0
Found legacy serial port 2 for /pci@400000000110/isa@3/serial@i898
port=898, taddr=3fd30000898, irq=0, clk=1843200, speed=0
Starting Linux PPC64 #7 SMP Thu Nov 30 15:59:33 CET 2006
-----------------------------------------------------
ppc64_pft_size = 0x0
physicalMemorySize = 0x200000000
ppc64_caches.dcache_line_size = 0x80
ppc64_caches.icache_line_size = 0x80
htab_address = 0xc0000001f0000000
htab_hash_mask = 0xfffff
-----------------------------------------------------
Linux version 2.6.19-ppc64-bug159235 (olaf@pomegranate) (gcc version 4.1.0 (SUSE Linux)) #7 SMP Thu Nov 30 15:59:33 CET 2006
[boot]0012 Setup Arch
Entering add_active_range(0, 0, 2097152) 0 entries of 256 used
No ramdisk, default root is /dev/sda2
EEH: PCI Enhanced I/O Error Handling Enabled
PPC64 nvram contains 81920 bytes
Using default idle loop
Top of RAM: 0x200000000, Total RAM: 0x200000000
Memory hole size: 0MB
Zone PFN ranges:
DMA 0 -> 2097152
Normal 2097152 -> 2097152
early_node_map[1] active PFN ranges
0: 0 -> 2097152
On node 0 totalpages: 2097152
DMA zone: 28672 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 2068480 pages, LIFO batch:31
Normal zone: 0 pages used for memmap
[boot]0015 Setup Done
Built 1 zonelists. Total pages: 2068480
Kernel command line: debug video=matroxfb:1280x1024@85 sysrq=1 panic=32 root=/dev/sdb2
[boot]0020 XICS Init
xics: PCI 8259 intack at 0x000003fffdf091f0
i8259 legacy interrupt controller initialized
[boot]0021 XICS Done
PID hash table entries: 4096 (order: 12, 32768 bytes)
time_init: decrementer frequency = 181.701290 MHz
time_init: processor frequency = 1453.000000 MHz
Console: colour dummy device 80x25
Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
Memory: 8102896k/8388608k available (3508k kernel code, 284972k reserved, 1072k data, 2273k bss, 180k init)
Calibrating delay loop... 362.90 BogoMIPS (lpj=1814528)
Mount-cache hash table entries: 256
Processor 1 found.
Processor 2 found.
Processor 3 found.
Brought up 4 CPUs
migration_cost=0
NET: Registered protocol family 16
PCI: Probing PCI hardware
Failed to request PCI IO region on PCI domain 0000
Using INTC for W82c105 IDE controller.
IOMMU table initialized, virtual merging enabled
ISA bridge at 0000:00:03.0
mapping IO 3fd30000000 -> d000080000000000, size: 100000
mapping IO 3fd50000000 -> d000080000100000, size: 100000
PCI: Probing PCI hardware done
SCSI subsystem initialized
NET: Registered protocol family 2
IP route cache hash table entries: 262144 (order: 9, 2097152 bytes)
TCP established hash table entries: 1048576 (order: 12, 16777216 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 1048576 bind 65536)
TCP reno registered
RTAS daemon started
RTAS: event: 188, Type: Internal Device Failure, Severity: 2
io scheduler noop registered (default)
matroxfb: Matrox G450 detected
PInS data found at offset 31168
PInS memtype = 4
matroxfb: 1280x1024x8bpp (virtual: 1280x13107)
matroxfb: framebuffer at 0x3FDEC000000, mapped to 0xd000080080009000, size 16777216
Console: switching to colour frame buffer device 160x64
fb0: MATROX frame buffer device
matroxfb_crtc2: secondary head of fb0 was registered as fb1
Generic RTC Driver v1.07
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250.0: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250.0: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
serial8250.0: ttyS2 at I/O 0x898 (irq = 10) is a 16550A
loop: loaded (max 8 devices)
e100: Intel(R) PRO/100 Network Driver, 3.5.17-k2-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
PCI: Enabling device: (0000:21:01.0), cmd 143
e100: eth0: e100_probe: addr 0x3fd88030000, irq 85, MAC addr 00:02:55:4F:05:C7
PCI: Enabling device: (0001:21:01.0), cmd 143
e100: eth1: e100_probe: addr 0x3fde8030000, irq 117, MAC addr 00:02:55:4F:05:D7
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
W82C105: IDE controller at PCI slot 0000:00:03.1
PCI: Enabling device: (0000:00:03.1), cmd 141
W82C105: chipset revision 5
W82C105: 100% native mode on irq 86
ide0: BM-DMA at 0xf040-0xf047, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xf048-0xf04f, BIOS settings: hdc:DMA, hdd:DMA
Probing IDE interface ide0...
hda: LG CD-ROM CRD-8484B, ATAPI CD/DVD-ROM drive
hda: selected PIO 4 (120ns) (0240)
ide0 at 0xf000-0xf007,0xf012 on irq 86
Probing IDE interface ide1...
hda: ATAPI 48X CD-ROM drive, 128kB Cache
Uniform CD-ROM driver Revision: 3.20
PCI: Enabling device: (0000:41:01.0), cmd 143
sym0: <1010-66> rev 0x1 at pci 0000:41:01.0 irq 87
sym0: No NVRAM, ID 7, Fast-80, LVD, parity checking
sym0: SCSI BUS has been reset.
scsi0 : sym-2.2.3
scsi 0:0:8:0: Direct-Access IBM IC35L036UCD210-0 S5BS PQ: 0 ANSI: 3
target0:0:8: tagged command queuing enabled, command queue depth 16.
target0:0:8: Beginning Domain Validation
target0:0:8: asynchronous
target0:0:8: wide asynchronous
target0:0:8: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31)
target0:0:8: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31)
target0:0:8: Ending Domain Validation
scsi 0:0:9:0: Direct-Access IBM IC35L036UCD210-0 S5BS PQ: 0 ANSI: 3
target0:0:9: tagged command queuing enabled, command queue depth 16.
target0:0:9: Beginning Domain Validation
target0:0:9: asynchronous
target0:0:9: wide asynchronous
target0:0:9: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31)
target0:0:9: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31)
target0:0:9: Ending Domain Validation
scsi 0:0:15:0: Enclosure IBM HSBPD4E PU3SCSI 0011 PQ: 0 ANSI: 2
target0:0:15: Beginning Domain Validation
scsi 0:0:15:0: phase change 6-7 6@40000fa0 resid=4.
target0:0:15: asynchronous
target0:0:15: Ending Domain Validation
PCI: Enabling device: (0000:41:01.1), cmd 143
sym1: <1010-66> rev 0x1 at pci 0000:41:01.1 irq 88
sym1: No NVRAM, ID 7, Fast-80, SE, parity checking
sym1: SCSI BUS has been reset.
scsi1 : sym-2.2.3
target1:0:0: FAST-20 WIDE SCSI 40.0 MB/s ST (50 ns, offset 31)
scsi 1:0:0:0: Sequential-Access HP IBM-C568303030!D C209 PQ: 0 ANSI: 2
target1:0:0: Beginning Domain Validation
target1:0:0: FAST-20 SCSI 20.0 MB/s ST (50 ns, offset 31)
target1:0:0: FAST-20 WIDE SCSI 40.0 MB/s ST (50 ns, offset 31)
target1:0:0: FAST-20 WIDE SCSI 40.0 MB/s ST (50 ns, offset 31)
target1:0:0: Domain Validation skipping write tests
target1:0:0: Ending Domain Validation
SCSI device sda: 71096640 512-byte hdwr sectors (36401 MB)
sda: Write Protect is off
sda: Mode Sense: cb 00 00 08
SCSI device sda: drive cache: write through
SCSI device sda: 71096640 512-byte hdwr sectors (36401 MB)
sda: Write Protect is off
sda: Mode Sense: cb 00 00 08
SCSI device sda: drive cache: write through
sda: sda1 sda2 sda3
sd 0:0:8:0: Attached scsi disk sda
SCSI device sdb: 71096640 512-byte hdwr sectors (36401 MB)
sdb: Write Protect is off
sdb: Mode Sense: cb 00 00 08
SCSI device sdb: drive cache: write through
SCSI device sdb: 71096640 512-byte hdwr sectors (36401 MB)
sdb: Write Protect is off
sdb: Mode Sense: cb 00 00 08
SCSI device sdb: drive cache: write through
sdb: sdb1 sdb2
sd 0:0:9:0: Attached scsi disk sdb
sd 0:0:8:0: Attached scsi generic sg0 type 0
sd 0:0:9:0: Attached scsi generic sg1 type 0
scsi 0:0:15:0: Attached scsi generic sg2 type 13
scsi 1:0:0:0: Attached scsi generic sg3 type 1
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
i2c /dev entries driver
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
input: AT Raw Set 2 keyboard as /class/input/input0
logips2pp: Detected unknown logitech mouse model 1
input: PS/2 Logitech Mouse as /class/input/input1
ReiserFS: sdb2: found reiserfs format "3.6" with standard journal
ReiserFS: sdb2: using ordered data mode
ReiserFS: sdb2: journal params: device sdb2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: sdb2: checking transaction log (sdb2)
ReiserFS: sdb2: Using r5 hash to sort names
VFS: Mounted root (reiserfs filesystem) readonly.
Freeing unused kernel memory: 180k freed
ioctl32(showconsole:353): Unknown cmd fd(0) cmd(40045432){00} arg(ffda1b38) on /dev/console
ioctl32(showconsole:388): Unknown cmd fd(0) cmd(40045432){00} arg(fff67ac8) on /dev/console
ReiserFS: sdb2: warning: acl not supported.
ReiserFS: sdb2: warning: user_xattr not supported.
ReiserFS: sdb2: warning: acl not supported.
ReiserFS: sdb2: warning: user_xattr not supported.
ioctl32(showconsole:958): Unknown cmd fd(0) cmd(40045432){00} arg(ff8fdac8) on /dev/console
ioctl32(showconsole:1130): Unknown cmd fd(0) cmd(40045432){00} arg(ff997ad8) on /dev/console
Adding 1048568k swap on /dev/sda2. Priority:-1 extents:1 across:1048568k
ioctl32(showconsole:1217): Unknown cmd fd(0) cmd(40045432){00} arg(ffe01b18) on /dev/console
e100: eth2: e100_watchdog: link up, 100Mbps, full-duplex
ioctl32(showconsole:2448): Unknown cmd fd(0) cmd(40045432){00} arg(ff821a78) on /dev/tty0
ISO 9660 Extensions: RRIP_1991A
==> /proc/ide <==
==> /proc/interrupts <==
CPU0 CPU1 CPU2 CPU3
1: 3 2 4 3 i8259 Level i8042
12: 28 28 27 26 i8259 Level i8042
16: 442 666 574 337 XICS Level IPI
86: 269 255 236 255 XICS Level ide0
87: 2243 2234 2260 2218 XICS Level sym53c8xx
88: 13 14 13 13 XICS Level sym53c8xx
117: 1714 1736 1727 1752 XICS Level eth2
BAD: 0
==> /proc/iomem <==
3fcc0000000-3fcc00fffff : PCI Bus #61
3fcc0000000-3fcc00fffff : PCI Bus #41
3fcc0000000-3fcc00fffff : PCI Bus #21
3fcc0000000-3fcc00fffff : PCI Bus #01
3fcc0000000-3fcc0007fff : 0000:00:02.6
3fcc0000000-3fcc0007fff : 0000:00:02.4
3fcc0000000-3fcc0007fff : 0000:00:02.2
3fd00000000-3fd000fffff : PCI Bus #61
3fd00000000-3fd000fffff : PCI Bus #21
3fd00000000-3fd000fffff : PCI Bus #01
3fd00000000-3fd00007fff : 0001:00:02.6
3fd00000000-3fd00007fff : 0001:00:02.2
3fd80000000-3fdbfffffff : /pci@400000000110
3fd80000000-3fd87ffffff : PCI Bus #01
3fd88000000-3fd8bffffff : PCI Bus #21
3fd88000000-3fd8801ffff : 0000:21:01.0
3fd88000000-3fd8801ffff : e100
3fd88020000-3fd8802ffff : 0000:21:01.0
3fd88030000-3fd88030fff : 0000:21:01.0
3fd88030000-3fd88030fff : e100
3fd8c000000-3fd8fffffff : PCI Bus #41
3fd8c000000-3fd8c001fff : 0000:41:01.1
3fd8c000000-3fd8c001fff : sym53c8xx
3fd8c002000-3fd8c003fff : 0000:41:01.0
3fd8c002000-3fd8c003fff : sym53c8xx
3fd8c004000-3fd8c0043ff : 0000:41:01.1
3fd8c004000-3fd8c0043ff : sym53c8xx
3fd8c005000-3fd8c0053ff : 0000:41:01.0
3fd8c005000-3fd8c0053ff : sym53c8xx
3fd90000000-3fd97ffffff : PCI Bus #61
3fd90000000-3fd90003fff : 0000:61:01.0
3fd9fff0000-3fd9fff7fff : 0000:00:02.0
3fdb4000000-3fdb7ffffff : 0000:00:01.0
3fdb8000000-3fdbbffffff : 0000:00:01.0
3fdbd700000-3fdbd700fff : 0000:00:01.0
3fdbd800000-3fdbd87ffff : 0000:00:01.0
3fde0000000-3fdffffffff : /pci@400000000112
3fde0000000-3fde7ffffff : PCI Bus #01
3fde0000000-3fde0000fff : 0001:01:01.3
3fde0001000-3fde0001fff : 0001:01:01.2
3fde0002000-3fde0002fff : 0001:01:01.1
3fde0003000-3fde0003fff : 0001:01:01.0
3fde8000000-3fdebffffff : PCI Bus #21
3fde8000000-3fde801ffff : 0001:21:01.0
3fde8000000-3fde801ffff : e100
3fde8020000-3fde802ffff : 0001:21:01.0
3fde8030000-3fde8030fff : 0001:21:01.0
3fde8030000-3fde8030fff : e100
3fdec000000-3fdf3ffffff : PCI Bus #61
3fdec000000-3fdef0fffff : PCI Bus #62
3fdec000000-3fdedffffff : 0001:62:00.0
3fdec000000-3fdedffffff : matroxfb FB
3fdee000000-3fdee7fffff : 0001:62:00.0
3fdee800000-3fdee803fff : 0001:62:00.0
3fdee800000-3fdee803fff : matroxfb MMIO
3fdef000000-3fdef01ffff : 0001:62:00.0
3fdffff0000-3fdffff7fff : 0001:00:02.0
==> /proc/ioports <==
00000000-0000001f : dma1
00000020-00000021 : 8259 (master)
00000040-0000005f : timer
00000060-0000006f : i8042
00000080-0000008f : dma page reg
000000a0-000000a1 : 8259 (slave)
000000c0-000000df : dma2
000002f8-000002ff : serial
000003c0-000003df : matrox
000003f8-000003ff : serial
000004d0-000004d1 : 8259 edge control
00000898-0000089f : serial
0000f000-0000f007 : 0000:00:03.1
0000f000-0000f007 : ide0
0000f010-0000f013 : 0000:00:03.1
0000f012-0000f012 : ide0
0000f020-0000f027 : 0000:00:03.1
0000f030-0000f033 : 0000:00:03.1
0000f040-0000f04f : 0000:00:03.1
0000f040-0000f047 : ide0
0000f048-0000f04f : ide1
00010000-0001ffff : PCI Bus #01
00020000-0002ffff : PCI Bus #21
0002ec00-0002ec3f : 0000:21:01.0
0002ec00-0002ec3f : e100
00030000-0003ffff : PCI Bus #41
0003e800-0003e8ff : 0000:41:01.0
0003e800-0003e8ff : sym53c8xx
0003ec00-0003ecff : 0000:41:01.1
0003ec00-0003ecff : sym53c8xx
00040000-0004ffff : PCI Bus #61
00100000-001fffff : /pci@400000000112
00100000-0010ffff : PCI Bus #01
00110000-0011ffff : PCI Bus #21
0011ec00-0011ec3f : 0001:21:01.0
0011ec00-0011ec3f : e100
00120000-0012ffff : PCI Bus #61
==> /proc/irq <==
00:01.0 Co-processor: IBM Unknown device 00e0 (rev 01) (prog-if ff)
Subsystem: IBM Unknown device 00e1
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: 72
Interrupt: pin A routed to IRQ 255
Region 0: Memory at 3fdbd700000 (32-bit, prefetchable) [size=4K]
Region 1: Memory at 3fdbd800000 (32-bit, prefetchable) [size=512K]
Region 2: Memory at 3fdb4000000 (32-bit, prefetchable) [size=64M]
Region 3: Memory at 3fdb8000000 (32-bit, prefetchable) [size=64M]
00:02.0 PCI bridge: IBM EADS-X PCI-X to PCI-X Bridge (rev 01) (prog-if 0f)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 248, Cache Line Size 20
BIST result: 00
Region 0: Memory at 3fd9fff0000 (64-bit, prefetchable) [size=32K]
Bus: primary=00, secondary=01, subordinate=10, sec-latency=248
I/O behind bridge: 00010000-0001ffff
Memory behind bridge: c0000000-c7ffffff
Prefetchable memory behind bridge: 0000000000000000-0000000000000000
Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset+ FastB2B-
Capabilities: [a0] PCI-X bridge device
Secondary Status: 64bit+ 133MHz+ SCD- USC- SCO- SRD- Freq=conv
Status: Dev=00:00.0 64bit+ 133MHz- SCD- USC- SCO- SRD-
Upstream: Capacity=0 CommitmentLimit=0
Downstream: Capacity=0 CommitmentLimit=0
Capabilities: [b0] Power Management version 2
Flags: PMEClk+ DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [b8] #0c [0000]
00:02.2 PCI bridge: IBM EADS-X PCI-X to PCI-X Bridge (rev 01) (prog-if 0f)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 248, Cache Line Size 20
BIST result: 00
Region 0: Memory at 3fcc0000000 (64-bit, prefetchable) [size=32K]
Bus: primary=00, secondary=21, subordinate=30, sec-latency=248
I/O behind bridge: 00020000-0002ffff
Memory behind bridge: c8000000-cbffffff
Prefetchable memory behind bridge: 0000000000000000-0000000000000000
Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
Capabilities: [a0] PCI-X bridge device
Secondary Status: 64bit- 133MHz- SCD- USC- SCO- SRD- Freq=conv
Status: Dev=00:00.2 64bit+ 133MHz- SCD- USC- SCO- SRD-
Upstream: Capacity=0 CommitmentLimit=0
Downstream: Capacity=0 CommitmentLimit=0
Capabilities: [b0] Power Management version 2
Flags: PMEClk+ DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [b8] #0c [0000]
00:02.4 PCI bridge: IBM EADS-X PCI-X to PCI-X Bridge (rev 01) (prog-if 0f)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 248, Cache Line Size 20
BIST result: 00
Region 0: Memory at 3fcc0000000 (64-bit, prefetchable) [size=32K]
Bus: primary=00, secondary=41, subordinate=50, sec-latency=248
I/O behind bridge: 00030000-0003ffff
Memory behind bridge: cc000000-cfffffff
Prefetchable memory behind bridge: 0000000000000000-0000000000000000
Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
Capabilities: [a0] PCI-X bridge device
Secondary Status: 64bit+ 133MHz+ SCD- USC- SCO- SRD- Freq=conv
Status: Dev=00:00.4 64bit+ 133MHz- SCD- USC- SCO- SRD-
Upstream: Capacity=0 CommitmentLimit=0
Downstream: Capacity=0 CommitmentLimit=0
Capabilities: [b0] Power Management version 2
Flags: PMEClk+ DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [b8] #0c [0000]
00:02.6 PCI bridge: IBM EADS-X PCI-X to PCI-X Bridge (rev 01) (prog-if 0f)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 248, Cache Line Size 20
BIST result: 00
Region 0: Memory at 3fcc0000000 (64-bit, prefetchable) [size=32K]
Bus: primary=00, secondary=61, subordinate=70, sec-latency=248
I/O behind bridge: 00040000-0004ffff
Memory behind bridge: d0000000-d7ffffff
Prefetchable memory behind bridge: 0000000000000000-0000000000000000
Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
Capabilities: [a0] PCI-X bridge device
Secondary Status: 64bit+ 133MHz+ SCD- USC- SCO- SRD- Freq=conv
Status: Dev=00:00.6 64bit+ 133MHz- SCD- USC- SCO- SRD-
Upstream: Capacity=0 CommitmentLimit=0
Downstream: Capacity=0 CommitmentLimit=0
Capabilities: [b0] Power Management version 2
Flags: PMEClk+ DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [b8] #0c [0000]
00:03.0 ISA bridge: Symphony Labs W83C553 (rev 10)
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
00:03.1 IDE interface: Symphony Labs SL82c105 (rev 05) (prog-if 8f [Master SecP SecO PriP PriO])
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: 72 (500ns min, 10000ns max), Cache Line Size 08
Interrupt: pin A routed to IRQ 86
Region 0: I/O ports at 3fd3000f000 [size=8]
Region 1: I/O ports at 3fd3000f010 [size=4]
Region 2: I/O ports at 3fd3000f020 [size=8]
Region 3: I/O ports at 3fd3000f030 [size=4]
Region 4: I/O ports at 3fd3000f040 [size=16]
Region 5: I/O ports at 3fd30000000 [size=16]
21:01.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 0d)
Subsystem: IBM Unknown device 01ff
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: 74 (2000ns min, 14000ns max)
Interrupt: pin A routed to IRQ 85
Region 0: Memory at 3fd88030000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at 3fd3002ec00 [size=64]
Region 2: Memory at 3fd88000000 (32-bit, non-prefetchable) [size=128K]
Expansion ROM at 3fd88020000 [disabled] [size=64K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
41:01.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1010 66MHz Ultra3 SCSI Adapter (rev 01)
Subsystem: LSI Logic / Symbios Logic LSI53C1000/1000R/1010R/1010-66 PCI to Ultra160 SCSI Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 74 (4250ns min, 4500ns max), Cache Line Size 20
Interrupt: pin A routed to IRQ 87
Region 0: I/O ports at 3fd3003e800 [size=256]
Region 1: Memory at 3fd8c005000 (64-bit, non-prefetchable) [size=1K]
Region 3: Memory at 3fd8c002000 (64-bit, non-prefetchable) [size=8K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
41:01.1 SCSI storage controller: LSI Logic / Symbios Logic 53c1010 66MHz Ultra3 SCSI Adapter (rev 01)
Subsystem: LSI Logic / Symbios Logic LSI53C1000/1000R/1010R/1010-66 PCI to Ultra160 SCSI Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 74 (4250ns min, 4500ns max), Cache Line Size 20
Interrupt: pin B routed to IRQ 88
Region 0: I/O ports at 3fd3003ec00 [size=256]
Region 1: Memory at 3fd8c004000 (64-bit, non-prefetchable) [size=1K]
Region 3: Memory at 3fd8c000000 (64-bit, non-prefetchable) [size=8K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
61:01.0 Ethernet controller: Alteon Networks Inc. AceNIC Gigabit Ethernet (rev 01)
Subsystem: IBM Gigabit Ethernet-SX PCI Adapter
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 89
Region 0: Memory at 3fd90000000 (32-bit, non-prefetchable) [disabled] [size=16K]
0001:00:02.0 PCI bridge: IBM EADS-X PCI-X to PCI-X Bridge (rev 01) (prog-if 0f)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 248, Cache Line Size 20
BIST result: 00
Region 0: Memory at 3fdffff0000 (64-bit, prefetchable) [size=32K]
Bus: primary=00, secondary=01, subordinate=10, sec-latency=248
I/O behind bridge: 00000000-0000ffff
Memory behind bridge: e0000000-e7ffffff
Prefetchable memory behind bridge: 0000000000000000-0000000000000000
Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
Capabilities: [a0] PCI-X bridge device
Secondary Status: 64bit+ 133MHz+ SCD- USC- SCO- SRD- Freq=conv
Status: Dev=00:02.0 64bit+ 133MHz+ SCD- USC- SCO- SRD-
Upstream: Capacity=0 CommitmentLimit=0
Downstream: Capacity=0 CommitmentLimit=0
Capabilities: [b0] Power Management version 2
Flags: PMEClk+ DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [b8] #0c [0000]
0001:00:02.2 PCI bridge: IBM EADS-X PCI-X to PCI-X Bridge (rev 01) (prog-if 0f)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 248, Cache Line Size 20
BIST result: 00
Region 0: Memory at 3fd00000000 (64-bit, prefetchable) [size=32K]
Bus: primary=00, secondary=21, subordinate=30, sec-latency=248
I/O behind bridge: 00010000-0001ffff
Memory behind bridge: e8000000-ebffffff
Prefetchable memory behind bridge: 0000000000000000-0000000000000000
Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
Capabilities: [a0] PCI-X bridge device
Secondary Status: 64bit- 133MHz- SCD- USC- SCO- SRD- Freq=conv
Status: Dev=00:02.2 64bit+ 133MHz+ SCD- USC- SCO- SRD-
Upstream: Capacity=0 CommitmentLimit=0
Downstream: Capacity=0 CommitmentLimit=0
Capabilities: [b0] Power Management version 2
Flags: PMEClk+ DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [b8] #0c [0000]
0001:00:02.6 PCI bridge: IBM EADS-X PCI-X to PCI-X Bridge (rev 01) (prog-if 0f)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 248, Cache Line Size 20
BIST result: 00
Region 0: Memory at 3fd00000000 (64-bit, prefetchable) [size=32K]
Bus: primary=00, secondary=61, subordinate=70, sec-latency=248
I/O behind bridge: 00020000-0002ffff
Memory behind bridge: ec000000-f3ffffff
Prefetchable memory behind bridge: 0000000000000000-0000000000000000
Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
Capabilities: [a0] PCI-X bridge device
Secondary Status: 64bit+ 133MHz+ SCD- USC- SCO- SRD- Freq=conv
Status: Dev=00:02.6 64bit+ 133MHz+ SCD- USC- SCO- SRD-
Upstream: Capacity=0 CommitmentLimit=0
Downstream: Capacity=0 CommitmentLimit=0
Capabilities: [b0] Power Management version 2
Flags: PMEClk+ DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [b8] #0c [0000]
0001:01:01.0 USB Controller: Agere Systems USS-344S USB Controller (rev 11) (prog-if 10 [OHCI])
Subsystem: Agere Systems USS-344S USB Controller
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 72 (750ns min, 21500ns max)
Interrupt: pin A routed to IRQ 115
Region 0: Memory at 3fde0003000 (32-bit, non-prefetchable) [size=4K]
0001:01:01.1 USB Controller: Agere Systems USS-344S USB Controller (rev 11) (prog-if 10 [OHCI])
Subsystem: Agere Systems USS-344S USB Controller
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 72 (750ns min, 21500ns max)
Interrupt: pin B routed to IRQ 116
Region 0: Memory at 3fde0002000 (32-bit, non-prefetchable) [size=4K]
0001:01:01.2 USB Controller: Agere Systems USS-344S USB Controller (rev 11) (prog-if 10 [OHCI])
Subsystem: Agere Systems USS-344S USB Controller
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 72 (750ns min, 21500ns max)
Interrupt: pin C routed to IRQ 115
Region 0: Memory at 3fde0001000 (32-bit, non-prefetchable) [size=4K]
0001:01:01.3 USB Controller: Agere Systems USS-344S USB Controller (rev 11) (prog-if 10 [OHCI])
Subsystem: Agere Systems USS-344S USB Controller
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 72 (750ns min, 21500ns max)
Interrupt: pin D routed to IRQ 116
Region 0: Memory at 3fde0000000 (32-bit, non-prefetchable) [size=4K]
0001:21:01.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 0d)
Subsystem: IBM Unknown device 01ff
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: 74 (2000ns min, 14000ns max)
Interrupt: pin A routed to IRQ 117
Region 0: Memory at 3fde8030000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at 3fd5001ec00 [size=64]
Region 2: Memory at 3fde8000000 (32-bit, non-prefetchable) [size=128K]
Expansion ROM at 3fde8020000 [disabled] [size=64K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
0001:61:01.0 PCI bridge: Hint Corp HB6 Universal PCI-PCI bridge (non-transparent mode) (rev 12) (prog-if 00 [Normal decode])
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: 74, Cache Line Size 08
Bus: primary=61, secondary=62, subordinate=62, sec-latency=128
I/O behind bridge: 01001000-01000fff
Memory behind bridge: ec000000-ef0fffff
Prefetchable memory behind bridge: 0000000001000000-0000000000f00000
Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [90] #06 [0000]
Capabilities: [a0] Vital Product Data
0001:62:00.0 VGA compatible controller: Matrox Graphics, Inc. G400/G450 (rev 82) (prog-if 00 [VGA])
Subsystem: IBM Unknown device 0233
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 121
Region 0: Memory at 3fdec000000 (32-bit, prefetchable) [size=32M]
Region 1: Memory at 3fdee800000 (32-bit, non-prefetchable) [size=16K]
Region 2: Memory at 3fdee000000 (32-bit, non-prefetchable) [size=8M]
Expansion ROM at 3fdef000000 [disabled] [size=128K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [f0] AGP version 2.0
Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2
Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<none>
[-- Attachment #3: winbond-libata.txt --]
[-- Type: text/plain, Size: 30756 bytes --]
Using pSeries machine description
Page orders: linear mapping = 24, virtual = 12, io = 12
Found legacy serial port 0 for /pci@400000000110/isa@3/serial@i3f8
port=3f8, taddr=3fd300003f8, irq=0, clk=1843200, speed=0
Found legacy serial port 1 for /pci@400000000110/isa@3/serial@i2f8
port=2f8, taddr=3fd300002f8, irq=0, clk=1843200, speed=0
Found legacy serial port 2 for /pci@400000000110/isa@3/serial@i898
port=898, taddr=3fd30000898, irq=0, clk=1843200, speed=0
Starting Linux PPC64 #8 SMP Thu Nov 30 17:33:10 CET 2006
-----------------------------------------------------
ppc64_pft_size = 0x0
physicalMemorySize = 0x200000000
ppc64_caches.dcache_line_size = 0x80
ppc64_caches.icache_line_size = 0x80
htab_address = 0xc0000001f0000000
htab_hash_mask = 0xfffff
-----------------------------------------------------
Linux version 2.6.19-ppc64-bug159235 (olaf@pomegranate) (gcc version 4.1.0 (SUSE Linux)) #8 SMP Thu Nov 30 17:33:10 CET 2006
[boot]0012 Setup Arch
Entering add_active_range(0, 0, 2097152) 0 entries of 256 used
No ramdisk, default root is /dev/sda2
EEH: PCI Enhanced I/O Error Handling Enabled
PPC64 nvram contains 81920 bytes
Using default idle loop
Top of RAM: 0x200000000, Total RAM: 0x200000000
Memory hole size: 0MB
Zone PFN ranges:
DMA 0 -> 2097152
Normal 2097152 -> 2097152
early_node_map[1] active PFN ranges
0: 0 -> 2097152
On node 0 totalpages: 2097152
DMA zone: 28672 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 2068480 pages, LIFO batch:31
Normal zone: 0 pages used for memmap
[boot]0015 Setup Done
Built 1 zonelists. Total pages: 2068480
Kernel command line: debug video=matroxfb:1280x1024@85 sysrq=1 panic=32 root=/dev/sdb2
[boot]0020 XICS Init
xics: PCI 8259 intack at 0x000003fffdf091f0
i8259 legacy interrupt controller initialized
[boot]0021 XICS Done
PID hash table entries: 4096 (order: 12, 32768 bytes)
time_init: decrementer frequency = 181.701788 MHz
time_init: processor frequency = 1453.000000 MHz
Console: colour dummy device 80x25
Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
Memory: 8103028k/8388608k available (3476k kernel code, 284888k reserved, 1060k data, 2236k bss, 176k init)
Calibrating delay loop... 362.90 BogoMIPS (lpj=1814528)
Mount-cache hash table entries: 256
Processor 1 found.
Processor 2 found.
Processor 3 found.
Brought up 4 CPUs
migration_cost=0
NET: Registered protocol family 16
PCI: Probing PCI hardware
Failed to request PCI IO region on PCI domain 0000
Using INTC for W82c105 IDE controller.
IOMMU table initialized, virtual merging enabled
ISA bridge at 0000:00:03.0
mapping IO 3fd30000000 -> d000080000000000, size: 100000
mapping IO 3fd50000000 -> d000080000100000, size: 100000
PCI: Probing PCI hardware done
SCSI subsystem initialized
libata version 2.00 loaded.
NET: Registered protocol family 2
IP route cache hash table entries: 262144 (order: 9, 2097152 bytes)
TCP established hash table entries: 1048576 (order: 12, 16777216 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 1048576 bind 65536)
TCP reno registered
RTAS daemon started
RTAS: event: 188, Type: Internal Device Failure, Severity: 2
io scheduler noop registered (default)
matroxfb: Matrox G450 detected
PInS data found at offset 31168
PInS memtype = 4
matroxfb: 1280x1024x8bpp (virtual: 1280x13107)
matroxfb: framebuffer at 0x3FDEC000000, mapped to 0xd000080080009000, size 16777216
Console: switching to colour frame buffer device 160x64
fb0: MATROX frame buffer device
matroxfb_crtc2: secondary head of fb0 was registered as fb1
Generic RTC Driver v1.07
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250.0: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250.0: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
serial8250.0: ttyS2 at I/O 0x898 (irq = 10) is a 16550A
loop: loaded (max 8 devices)
e100: Intel(R) PRO/100 Network Driver, 3.5.17-k2-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
PCI: Enabling device: (0000:21:01.0), cmd 143
e100: eth0: e100_probe: addr 0x3fd88030000, irq 85, MAC addr 00:02:55:4F:05:C7
PCI: Enabling device: (0001:21:01.0), cmd 143
e100: eth1: e100_probe: addr 0x3fde8030000, irq 117, MAC addr 00:02:55:4F:05:D7
PCI: Enabling device: (0000:41:01.0), cmd 143
sym0: <1010-66> rev 0x1 at pci 0000:41:01.0 irq 87
sym0: No NVRAM, ID 7, Fast-80, LVD, parity checking
sym0: SCSI BUS has been reset.
scsi0 : sym-2.2.3
scsi 0:0:8:0: Direct-Access IBM IC35L036UCD210-0 S5BS PQ: 0 ANSI: 3
target0:0:8: tagged command queuing enabled, command queue depth 16.
target0:0:8: Beginning Domain Validation
target0:0:8: asynchronous
target0:0:8: wide asynchronous
target0:0:8: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31)
target0:0:8: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31)
target0:0:8: Ending Domain Validation
scsi 0:0:9:0: Direct-Access IBM IC35L036UCD210-0 S5BS PQ: 0 ANSI: 3
target0:0:9: tagged command queuing enabled, command queue depth 16.
target0:0:9: Beginning Domain Validation
target0:0:9: asynchronous
target0:0:9: wide asynchronous
target0:0:9: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31)
target0:0:9: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31)
target0:0:9: Ending Domain Validation
scsi 0:0:15:0: Enclosure IBM HSBPD4E PU3SCSI 0011 PQ: 0 ANSI: 2
target0:0:15: Beginning Domain Validation
scsi 0:0:15:0: phase change 6-7 6@40000fa0 resid=4.
target0:0:15: asynchronous
target0:0:15: Ending Domain Validation
PCI: Enabling device: (0000:41:01.1), cmd 143
sym1: <1010-66> rev 0x1 at pci 0000:41:01.1 irq 88
sym1: No NVRAM, ID 7, Fast-80, SE, parity checking
sym1: SCSI BUS has been reset.
scsi1 : sym-2.2.3
target1:0:0: FAST-20 WIDE SCSI 40.0 MB/s ST (50 ns, offset 31)
scsi 1:0:0:0: Sequential-Access HP IBM-C568303030!D C209 PQ: 0 ANSI: 2
target1:0:0: Beginning Domain Validation
target1:0:0: FAST-20 SCSI 20.0 MB/s ST (50 ns, offset 31)
target1:0:0: FAST-20 WIDE SCSI 40.0 MB/s ST (50 ns, offset 31)
target1:0:0: FAST-20 WIDE SCSI 40.0 MB/s ST (50 ns, offset 31)
target1:0:0: Domain Validation skipping write tests
target1:0:0: Ending Domain Validation
SCSI device sda: 71096640 512-byte hdwr sectors (36401 MB)
sda: Write Protect is off
sda: Mode Sense: cb 00 00 08
SCSI device sda: drive cache: write through
SCSI device sda: 71096640 512-byte hdwr sectors (36401 MB)
sda: Write Protect is off
sda: Mode Sense: cb 00 00 08
SCSI device sda: drive cache: write through
sda: sda1 sda2 sda3
sd 0:0:8:0: Attached scsi disk sda
SCSI device sdb: 71096640 512-byte hdwr sectors (36401 MB)
sdb: Write Protect is off
sdb: Mode Sense: cb 00 00 08
SCSI device sdb: drive cache: write through
SCSI device sdb: 71096640 512-byte hdwr sectors (36401 MB)
sdb: Write Protect is off
sdb: Mode Sense: cb 00 00 08
SCSI device sdb: drive cache: write through
sdb: sdb1 sdb2
sd 0:0:9:0: Attached scsi disk sdb
sd 0:0:8:0: Attached scsi generic sg0 type 0
sd 0:0:9:0: Attached scsi generic sg1 type 0
scsi 0:0:15:0: Attached scsi generic sg2 type 13
scsi 1:0:0:0: Attached scsi generic sg3 type 1
PCI: Enabling device: (0000:00:03.1), cmd 141
PCI: Unable to reserve I/O region #6:10@0 for device 0000:00:03.1
pata_sl82c105: probe of 0000:00:03.1 failed with error -16
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
i2c /dev entries driver
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
input: AT Raw Set 2 keyboard as /class/input/input0
logips2pp: Detected unknown logitech mouse model 1
input: PS/2 Logitech Mouse as /class/input/input1
ReiserFS: sdb2: found reiserfs format "3.6" with standard journal
ReiserFS: sdb2: using ordered data mode
ReiserFS: sdb2: journal params: device sdb2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: sdb2: checking transaction log (sdb2)
ReiserFS: sdb2: Using r5 hash to sort names
VFS: Mounted root (reiserfs filesystem) readonly.
Freeing unused kernel memory: 176k freed
ioctl32(showconsole:355): Unknown cmd fd(0) cmd(40045432){00} arg(ffa32b38) on /dev/console
ioctl32(showconsole:390): Unknown cmd fd(0) cmd(40045432){00} arg(fffb4ac8) on /dev/console
ReiserFS: sdb2: warning: acl not supported.
ReiserFS: sdb2: warning: user_xattr not supported.
ReiserFS: sdb2: warning: acl not supported.
ReiserFS: sdb2: warning: user_xattr not supported.
ioctl32(showconsole:953): Unknown cmd fd(0) cmd(40045432){00} arg(ffc97ac8) on /dev/console
ioctl32(showconsole:1125): Unknown cmd fd(0) cmd(40045432){00} arg(fff9bad8) on /dev/console
Adding 1048568k swap on /dev/sda2. Priority:-1 extents:1 across:1048568k
ioctl32(showconsole:1212): Unknown cmd fd(0) cmd(40045432){00} arg(ffb99b18) on /dev/console
e100: eth2: e100_watchdog: link up, 100Mbps, full-duplex
ioctl32(showconsole:2409): Unknown cmd fd(0) cmd(40045432){00} arg(fff1fa78) on /dev/tty0
==> /proc/interrupts <==
CPU0 CPU1 CPU2 CPU3
1: 3 3 2 4 i8259 Level i8042
12: 26 28 28 27 i8259 Level i8042
16: 254 597 403 583 XICS Level IPI
87: 2088 2071 2092 2088 XICS Level sym53c8xx
88: 13 13 14 13 XICS Level sym53c8xx
117: 490 506 484 489 XICS Level eth2
BAD: 0
==> /proc/iomem <==
3fcc0000000-3fcc00fffff : PCI Bus #61
3fcc0000000-3fcc00fffff : PCI Bus #41
3fcc0000000-3fcc00fffff : PCI Bus #21
3fcc0000000-3fcc00fffff : PCI Bus #01
3fcc0000000-3fcc0007fff : 0000:00:02.6
3fcc0000000-3fcc0007fff : 0000:00:02.4
3fcc0000000-3fcc0007fff : 0000:00:02.2
3fd00000000-3fd000fffff : PCI Bus #61
3fd00000000-3fd000fffff : PCI Bus #21
3fd00000000-3fd000fffff : PCI Bus #01
3fd00000000-3fd00007fff : 0001:00:02.6
3fd00000000-3fd00007fff : 0001:00:02.2
3fd80000000-3fdbfffffff : /pci@400000000110
3fd80000000-3fd87ffffff : PCI Bus #01
3fd88000000-3fd8bffffff : PCI Bus #21
3fd88000000-3fd8801ffff : 0000:21:01.0
3fd88000000-3fd8801ffff : e100
3fd88020000-3fd8802ffff : 0000:21:01.0
3fd88030000-3fd88030fff : 0000:21:01.0
3fd88030000-3fd88030fff : e100
3fd8c000000-3fd8fffffff : PCI Bus #41
3fd8c000000-3fd8c001fff : 0000:41:01.1
3fd8c000000-3fd8c001fff : sym53c8xx
3fd8c002000-3fd8c003fff : 0000:41:01.0
3fd8c002000-3fd8c003fff : sym53c8xx
3fd8c004000-3fd8c0043ff : 0000:41:01.1
3fd8c004000-3fd8c0043ff : sym53c8xx
3fd8c005000-3fd8c0053ff : 0000:41:01.0
3fd8c005000-3fd8c0053ff : sym53c8xx
3fd90000000-3fd97ffffff : PCI Bus #61
3fd90000000-3fd90003fff : 0000:61:01.0
3fd9fff0000-3fd9fff7fff : 0000:00:02.0
3fdb4000000-3fdb7ffffff : 0000:00:01.0
3fdb8000000-3fdbbffffff : 0000:00:01.0
3fdbd700000-3fdbd700fff : 0000:00:01.0
3fdbd800000-3fdbd87ffff : 0000:00:01.0
3fde0000000-3fdffffffff : /pci@400000000112
3fde0000000-3fde7ffffff : PCI Bus #01
3fde0000000-3fde0000fff : 0001:01:01.3
3fde0001000-3fde0001fff : 0001:01:01.2
3fde0002000-3fde0002fff : 0001:01:01.1
3fde0003000-3fde0003fff : 0001:01:01.0
3fde8000000-3fdebffffff : PCI Bus #21
3fde8000000-3fde801ffff : 0001:21:01.0
3fde8000000-3fde801ffff : e100
3fde8020000-3fde802ffff : 0001:21:01.0
3fde8030000-3fde8030fff : 0001:21:01.0
3fde8030000-3fde8030fff : e100
3fdec000000-3fdf3ffffff : PCI Bus #61
3fdec000000-3fdef0fffff : PCI Bus #62
3fdec000000-3fdedffffff : 0001:62:00.0
3fdec000000-3fdedffffff : matroxfb FB
3fdee000000-3fdee7fffff : 0001:62:00.0
3fdee800000-3fdee803fff : 0001:62:00.0
3fdee800000-3fdee803fff : matroxfb MMIO
3fdef000000-3fdef01ffff : 0001:62:00.0
3fdffff0000-3fdffff7fff : 0001:00:02.0
==> /proc/ioports <==
00000000-0000001f : dma1
00000020-00000021 : 8259 (master)
00000040-0000005f : timer
00000060-0000006f : i8042
00000080-0000008f : dma page reg
000000a0-000000a1 : 8259 (slave)
000000c0-000000df : dma2
000002f8-000002ff : serial
000003c0-000003df : matrox
000003f8-000003ff : serial
000004d0-000004d1 : 8259 edge control
00000898-0000089f : serial
0000f000-0000f007 : 0000:00:03.1
0000f010-0000f013 : 0000:00:03.1
0000f020-0000f027 : 0000:00:03.1
0000f030-0000f033 : 0000:00:03.1
0000f040-0000f04f : 0000:00:03.1
00010000-0001ffff : PCI Bus #01
00020000-0002ffff : PCI Bus #21
0002ec00-0002ec3f : 0000:21:01.0
0002ec00-0002ec3f : e100
00030000-0003ffff : PCI Bus #41
0003e800-0003e8ff : 0000:41:01.0
0003e800-0003e8ff : sym53c8xx
0003ec00-0003ecff : 0000:41:01.1
0003ec00-0003ecff : sym53c8xx
00040000-0004ffff : PCI Bus #61
00100000-001fffff : /pci@400000000112
00100000-0010ffff : PCI Bus #01
00110000-0011ffff : PCI Bus #21
0011ec00-0011ec3f : 0001:21:01.0
0011ec00-0011ec3f : e100
00120000-0012ffff : PCI Bus #61
==> /proc/irq <==
00:01.0 Co-processor: IBM Unknown device 00e0 (rev 01) (prog-if ff)
Subsystem: IBM Unknown device 00e1
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: 72
Interrupt: pin A routed to IRQ 255
Region 0: Memory at 3fdbd700000 (32-bit, prefetchable) [size=4K]
Region 1: Memory at 3fdbd800000 (32-bit, prefetchable) [size=512K]
Region 2: Memory at 3fdb4000000 (32-bit, prefetchable) [size=64M]
Region 3: Memory at 3fdb8000000 (32-bit, prefetchable) [size=64M]
00:02.0 PCI bridge: IBM EADS-X PCI-X to PCI-X Bridge (rev 01) (prog-if 0f)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 248, Cache Line Size 20
BIST result: 00
Region 0: Memory at 3fd9fff0000 (64-bit, prefetchable) [size=32K]
Bus: primary=00, secondary=01, subordinate=10, sec-latency=248
I/O behind bridge: 00010000-0001ffff
Memory behind bridge: c0000000-c7ffffff
Prefetchable memory behind bridge: 0000000000000000-0000000000000000
Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset+ FastB2B-
Capabilities: [a0] PCI-X bridge device
Secondary Status: 64bit+ 133MHz+ SCD- USC- SCO- SRD- Freq=conv
Status: Dev=00:00.0 64bit+ 133MHz- SCD- USC- SCO- SRD-
Upstream: Capacity=0 CommitmentLimit=0
Downstream: Capacity=0 CommitmentLimit=0
Capabilities: [b0] Power Management version 2
Flags: PMEClk+ DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [b8] #0c [0000]
00:02.2 PCI bridge: IBM EADS-X PCI-X to PCI-X Bridge (rev 01) (prog-if 0f)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 248, Cache Line Size 20
BIST result: 00
Region 0: Memory at 3fcc0000000 (64-bit, prefetchable) [size=32K]
Bus: primary=00, secondary=21, subordinate=30, sec-latency=248
I/O behind bridge: 00020000-0002ffff
Memory behind bridge: c8000000-cbffffff
Prefetchable memory behind bridge: 0000000000000000-0000000000000000
Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
Capabilities: [a0] PCI-X bridge device
Secondary Status: 64bit- 133MHz- SCD- USC- SCO- SRD- Freq=conv
Status: Dev=00:00.2 64bit+ 133MHz- SCD- USC- SCO- SRD-
Upstream: Capacity=0 CommitmentLimit=0
Downstream: Capacity=0 CommitmentLimit=0
Capabilities: [b0] Power Management version 2
Flags: PMEClk+ DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [b8] #0c [0000]
00:02.4 PCI bridge: IBM EADS-X PCI-X to PCI-X Bridge (rev 01) (prog-if 0f)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 248, Cache Line Size 20
BIST result: 00
Region 0: Memory at 3fcc0000000 (64-bit, prefetchable) [size=32K]
Bus: primary=00, secondary=41, subordinate=50, sec-latency=248
I/O behind bridge: 00030000-0003ffff
Memory behind bridge: cc000000-cfffffff
Prefetchable memory behind bridge: 0000000000000000-0000000000000000
Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
Capabilities: [a0] PCI-X bridge device
Secondary Status: 64bit+ 133MHz+ SCD- USC- SCO- SRD- Freq=conv
Status: Dev=00:00.4 64bit+ 133MHz- SCD- USC- SCO- SRD-
Upstream: Capacity=0 CommitmentLimit=0
Downstream: Capacity=0 CommitmentLimit=0
Capabilities: [b0] Power Management version 2
Flags: PMEClk+ DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [b8] #0c [0000]
00:02.6 PCI bridge: IBM EADS-X PCI-X to PCI-X Bridge (rev 01) (prog-if 0f)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 248, Cache Line Size 20
BIST result: 00
Region 0: Memory at 3fcc0000000 (64-bit, prefetchable) [size=32K]
Bus: primary=00, secondary=61, subordinate=70, sec-latency=248
I/O behind bridge: 00040000-0004ffff
Memory behind bridge: d0000000-d7ffffff
Prefetchable memory behind bridge: 0000000000000000-0000000000000000
Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
Capabilities: [a0] PCI-X bridge device
Secondary Status: 64bit+ 133MHz+ SCD- USC- SCO- SRD- Freq=conv
Status: Dev=00:00.6 64bit+ 133MHz- SCD- USC- SCO- SRD-
Upstream: Capacity=0 CommitmentLimit=0
Downstream: Capacity=0 CommitmentLimit=0
Capabilities: [b0] Power Management version 2
Flags: PMEClk+ DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [b8] #0c [0000]
00:03.0 ISA bridge: Symphony Labs W83C553 (rev 10)
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
00:03.1 IDE interface: Symphony Labs SL82c105 (rev 05) (prog-if 8f [Master SecP SecO PriP PriO])
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 86
Region 0: I/O ports at 3fd3000f000 [size=8]
Region 1: I/O ports at 3fd3000f010 [size=4]
Region 2: I/O ports at 3fd3000f020 [size=8]
Region 3: I/O ports at 3fd3000f030 [size=4]
Region 4: I/O ports at 3fd3000f040 [size=16]
Region 5: I/O ports at 3fd30000000 [size=16]
21:01.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 0d)
Subsystem: IBM Unknown device 01ff
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: 74 (2000ns min, 14000ns max)
Interrupt: pin A routed to IRQ 85
Region 0: Memory at 3fd88030000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at 3fd3002ec00 [size=64]
Region 2: Memory at 3fd88000000 (32-bit, non-prefetchable) [size=128K]
Expansion ROM at 3fd88020000 [disabled] [size=64K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
41:01.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1010 66MHz Ultra3 SCSI Adapter (rev 01)
Subsystem: LSI Logic / Symbios Logic LSI53C1000/1000R/1010R/1010-66 PCI to Ultra160 SCSI Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 74 (4250ns min, 4500ns max), Cache Line Size 20
Interrupt: pin A routed to IRQ 87
Region 0: I/O ports at 3fd3003e800 [size=256]
Region 1: Memory at 3fd8c005000 (64-bit, non-prefetchable) [size=1K]
Region 3: Memory at 3fd8c002000 (64-bit, non-prefetchable) [size=8K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
41:01.1 SCSI storage controller: LSI Logic / Symbios Logic 53c1010 66MHz Ultra3 SCSI Adapter (rev 01)
Subsystem: LSI Logic / Symbios Logic LSI53C1000/1000R/1010R/1010-66 PCI to Ultra160 SCSI Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 74 (4250ns min, 4500ns max), Cache Line Size 20
Interrupt: pin B routed to IRQ 88
Region 0: I/O ports at 3fd3003ec00 [size=256]
Region 1: Memory at 3fd8c004000 (64-bit, non-prefetchable) [size=1K]
Region 3: Memory at 3fd8c000000 (64-bit, non-prefetchable) [size=8K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
61:01.0 Ethernet controller: Alteon Networks Inc. AceNIC Gigabit Ethernet (rev 01)
Subsystem: IBM Gigabit Ethernet-SX PCI Adapter
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 89
Region 0: Memory at 3fd90000000 (32-bit, non-prefetchable) [disabled] [size=16K]
0001:00:02.0 PCI bridge: IBM EADS-X PCI-X to PCI-X Bridge (rev 01) (prog-if 0f)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 248, Cache Line Size 20
BIST result: 00
Region 0: Memory at 3fdffff0000 (64-bit, prefetchable) [size=32K]
Bus: primary=00, secondary=01, subordinate=10, sec-latency=248
I/O behind bridge: 00000000-0000ffff
Memory behind bridge: e0000000-e7ffffff
Prefetchable memory behind bridge: 0000000000000000-0000000000000000
Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
Capabilities: [a0] PCI-X bridge device
Secondary Status: 64bit+ 133MHz+ SCD- USC- SCO- SRD- Freq=conv
Status: Dev=00:02.0 64bit+ 133MHz+ SCD- USC- SCO- SRD-
Upstream: Capacity=0 CommitmentLimit=0
Downstream: Capacity=0 CommitmentLimit=0
Capabilities: [b0] Power Management version 2
Flags: PMEClk+ DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [b8] #0c [0000]
0001:00:02.2 PCI bridge: IBM EADS-X PCI-X to PCI-X Bridge (rev 01) (prog-if 0f)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 248, Cache Line Size 20
BIST result: 00
Region 0: Memory at 3fd00000000 (64-bit, prefetchable) [size=32K]
Bus: primary=00, secondary=21, subordinate=30, sec-latency=248
I/O behind bridge: 00010000-0001ffff
Memory behind bridge: e8000000-ebffffff
Prefetchable memory behind bridge: 0000000000000000-0000000000000000
Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
Capabilities: [a0] PCI-X bridge device
Secondary Status: 64bit- 133MHz- SCD- USC- SCO- SRD- Freq=conv
Status: Dev=00:02.2 64bit+ 133MHz+ SCD- USC- SCO- SRD-
Upstream: Capacity=0 CommitmentLimit=0
Downstream: Capacity=0 CommitmentLimit=0
Capabilities: [b0] Power Management version 2
Flags: PMEClk+ DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [b8] #0c [0000]
0001:00:02.6 PCI bridge: IBM EADS-X PCI-X to PCI-X Bridge (rev 01) (prog-if 0f)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 248, Cache Line Size 20
BIST result: 00
Region 0: Memory at 3fd00000000 (64-bit, prefetchable) [size=32K]
Bus: primary=00, secondary=61, subordinate=70, sec-latency=248
I/O behind bridge: 00020000-0002ffff
Memory behind bridge: ec000000-f3ffffff
Prefetchable memory behind bridge: 0000000000000000-0000000000000000
Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
Capabilities: [a0] PCI-X bridge device
Secondary Status: 64bit+ 133MHz+ SCD- USC- SCO- SRD- Freq=conv
Status: Dev=00:02.6 64bit+ 133MHz+ SCD- USC- SCO- SRD-
Upstream: Capacity=0 CommitmentLimit=0
Downstream: Capacity=0 CommitmentLimit=0
Capabilities: [b0] Power Management version 2
Flags: PMEClk+ DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [b8] #0c [0000]
0001:01:01.0 USB Controller: Agere Systems USS-344S USB Controller (rev 11) (prog-if 10 [OHCI])
Subsystem: Agere Systems USS-344S USB Controller
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 72 (750ns min, 21500ns max)
Interrupt: pin A routed to IRQ 115
Region 0: Memory at 3fde0003000 (32-bit, non-prefetchable) [size=4K]
0001:01:01.1 USB Controller: Agere Systems USS-344S USB Controller (rev 11) (prog-if 10 [OHCI])
Subsystem: Agere Systems USS-344S USB Controller
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 72 (750ns min, 21500ns max)
Interrupt: pin B routed to IRQ 116
Region 0: Memory at 3fde0002000 (32-bit, non-prefetchable) [size=4K]
0001:01:01.2 USB Controller: Agere Systems USS-344S USB Controller (rev 11) (prog-if 10 [OHCI])
Subsystem: Agere Systems USS-344S USB Controller
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 72 (750ns min, 21500ns max)
Interrupt: pin C routed to IRQ 115
Region 0: Memory at 3fde0001000 (32-bit, non-prefetchable) [size=4K]
0001:01:01.3 USB Controller: Agere Systems USS-344S USB Controller (rev 11) (prog-if 10 [OHCI])
Subsystem: Agere Systems USS-344S USB Controller
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 72 (750ns min, 21500ns max)
Interrupt: pin D routed to IRQ 116
Region 0: Memory at 3fde0000000 (32-bit, non-prefetchable) [size=4K]
0001:21:01.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 0d)
Subsystem: IBM Unknown device 01ff
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: 74 (2000ns min, 14000ns max)
Interrupt: pin A routed to IRQ 117
Region 0: Memory at 3fde8030000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at 3fd5001ec00 [size=64]
Region 2: Memory at 3fde8000000 (32-bit, non-prefetchable) [size=128K]
Expansion ROM at 3fde8020000 [disabled] [size=64K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
0001:61:01.0 PCI bridge: Hint Corp HB6 Universal PCI-PCI bridge (non-transparent mode) (rev 12) (prog-if 00 [Normal decode])
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: 74, Cache Line Size 08
Bus: primary=61, secondary=62, subordinate=62, sec-latency=128
I/O behind bridge: 01001000-01000fff
Memory behind bridge: ec000000-ef0fffff
Prefetchable memory behind bridge: 0000000001000000-0000000000f00000
Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [90] #06 [0000]
Capabilities: [a0] Vital Product Data
0001:62:00.0 VGA compatible controller: Matrox Graphics, Inc. G400/G450 (rev 82) (prog-if 00 [VGA])
Subsystem: IBM Unknown device 0233
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 121
Region 0: Memory at 3fdec000000 (32-bit, prefetchable) [size=32M]
Region 1: Memory at 3fdee800000 (32-bit, non-prefetchable) [size=16K]
Region 2: Memory at 3fdee000000 (32-bit, non-prefetchable) [size=8M]
Expansion ROM at 3fdef000000 [disabled] [size=128K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [f0] AGP version 2.0
Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2
Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<none>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: pata_sl82c105 can not reserve IO region
2006-11-30 16:52 pata_sl82c105 can not reserve IO region Olaf Hering
@ 2006-11-30 17:10 ` Alan
2006-11-30 18:47 ` Olaf Hering
2006-12-03 17:12 ` Olaf Hering
` (2 subsequent siblings)
3 siblings, 1 reply; 95+ messages in thread
From: Alan @ 2006-11-30 17:10 UTC (permalink / raw)
To: Olaf Hering, linux-ide, linuxppc-dev
On Thu, 30 Nov 2006 17:52:02 +0100 (MET)
Olaf Hering <olaf@aepfle.de> wrote:
>
> pata_sl82c105 can be used on the ppc64 POWER4 system p610, p615 and p630
> for the onboard IDE CD drive. It could be also used for ppc32 Motorola
> PowerStack PReP systems.
>
> Unfortunately, it doesnt work for me on the p630:
>
> PCI: Enabling device: (0000:00:03.1), cmd 141
> PCI: Unable to reserve I/O region #6:10@0 for device 0000:00:03.1
> pata_sl82c105: probe of 0000:00:03.1 failed with error -16
>
> Any idea how to fix it properly?
That looks like a compiler bug.
I/O region #6.
pci_request_regions() and pci_request_selcted_regions() end up in a loop
calling pci_request_region with the values 0 to 5. Never 6.
Can you instrument that code a bit and see wtf is going on first of all.
Alan
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: pata_sl82c105 can not reserve IO region
2006-11-30 17:10 ` Alan
@ 2006-11-30 18:47 ` Olaf Hering
2006-12-01 18:34 ` Olaf Hering
0 siblings, 1 reply; 95+ messages in thread
From: Olaf Hering @ 2006-11-30 18:47 UTC (permalink / raw)
To: Alan; +Cc: linux-ide, linuxppc-dev
On Thu, Nov 30, Alan wrote:
> I/O region #6.
>
> pci_request_regions() and pci_request_selcted_regions() end up in a loop
> calling pci_request_region with the values 0 to 5. Never 6.
The printk in pci_request_region has 'bar + 1', so 6 should be possible
if i becomes 5.
I see the failure in 2.6.16 and 2.6.18 too, if that matters. Will look
at it tomorrow.
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: pata_sl82c105 can not reserve IO region
2006-11-30 18:47 ` Olaf Hering
@ 2006-12-01 18:34 ` Olaf Hering
2006-12-01 18:58 ` Alan
2006-12-01 19:05 ` Sergei Shtylyov
0 siblings, 2 replies; 95+ messages in thread
From: Olaf Hering @ 2006-12-01 18:34 UTC (permalink / raw)
To: Alan; +Cc: linux-ide, linuxppc-dev
On Thu, Nov 30, Olaf Hering wrote:
> On Thu, Nov 30, Alan wrote:
>
> > I/O region #6.
> >
> > pci_request_regions() and pci_request_selcted_regions() end up in a loop
> > calling pci_request_region with the values 0 to 5. Never 6.
>
> The printk in pci_request_region has 'bar + 1', so 6 should be possible
> if i becomes 5.
Does the IO region of the last bar look correct?
00:03.1 IDE interface: Symphony Labs SL82c105 (rev 05) (prog-if 8f [Master SecP SecO PriP PriO])
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 86
Region 0: I/O ports at 3fd3000f000 [size=8]
Region 1: I/O ports at 3fd3000f010 [size=4]
Region 2: I/O ports at 3fd3000f020 [size=8]
Region 3: I/O ports at 3fd3000f030 [size=4]
Region 4: I/O ports at 3fd3000f040 [size=16]
Region 5: I/O ports at 3fd30000000 [size=16]
00: ad 10 05 01 41 01 80 02 05 8f 01 01 08 48 80 00
10: 01 f0 00 00 11 f0 00 00 21 f0 00 00 31 f0 00 00
20: 41 f0 00 00 01 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 56 01 02 28
40: b3 08 ff 00 09 09 00 00 09 09 00 00 09 09 00 00
50: 09 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
name "ide"
linux,phandle 00d5cdc0 (14011840)
assigned-addresses 81001910 00000000 0000f000 00000000 00000008 81001914
00000000 0000f010 00000000 00000004 81001918 00000000
0000f020 00000000 00000008 8100191c 00000000 0000f030
00000000 00000004 81001920 00000000 0000f040 00000000
00000010 81001924 00000000 00000000 00000000 00000010
interrupts 00000003
built-in
#size-cells 00000000
#address-cells 00000001
device_type "ide"
reg 00001900 00000000 00000000 00000000 00000000
41001910 00000000 00000000 00000000 00000008
41001914 00000000 00000000 00000000 00000004
41001918 00000000 00000000 00000000 00000008
4100191c 00000000 00000000 00000000 00000004
41001920 00000000 00000000 00000000 00000010
41001924 00000000 00000000 00000000 00000010
compatible "pci10ad,105"
"pciclass,01018f"
ibm,fw-slot-number 00000000
fast-back-to-back
devsel-speed 00000001
max-latency 00000028 (40)
min-grant 00000002
class-code 0001018f (65935)
revision-id 00000005
device-id 00000105 (261)
vendor-id 000010ad (4269)
ibm,loc-code "U0.1-P1/Q6"
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: pata_sl82c105 can not reserve IO region
2006-12-01 18:34 ` Olaf Hering
@ 2006-12-01 18:58 ` Alan
2006-12-01 19:05 ` Sergei Shtylyov
1 sibling, 0 replies; 95+ messages in thread
From: Alan @ 2006-12-01 18:58 UTC (permalink / raw)
To: Olaf Hering; +Cc: linux-ide, linuxppc-dev
On Fri, 1 Dec 2006 19:34:16 +0100 (MET)
Olaf Hering <olaf@aepfle.de> wrote:
> > The printk in pci_request_region has 'bar + 1', so 6 should be possible
> > if i becomes 5.
>
> Does the IO region of the last bar look correct?
I've no idea. That really depends upon the platform.
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: pata_sl82c105 can not reserve IO region
2006-12-01 18:34 ` Olaf Hering
@ 2006-12-01 19:05 ` Sergei Shtylyov
2006-12-01 19:05 ` Sergei Shtylyov
1 sibling, 0 replies; 95+ messages in thread
From: Sergei Shtylyov @ 2006-12-01 19:05 UTC (permalink / raw)
To: Olaf Hering; +Cc: Alan, linux-ide, linuxppc-dev
Olaf Hering wrote:
>>The printk in pci_request_region has 'bar + 1', so 6 should be possible
>>if i becomes 5.
> Does the IO region of the last bar look correct?
I'd say it looks suspicious since it's not adjacent to all the other
regions... In fact, after looking at your /proc/ioports/ I can say that the
BAR is actually unassigned and its *actual* value is 0 which the driver may
not like (the ones that lspci show are the physical memory addresses not the
actual I/O space addresses in this case). That's why the reservation fails.
> 00:03.1 IDE interface: Symphony Labs SL82c105 (rev 05) (prog-if 8f [Master SecP SecO PriP PriO])
> 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 86
> Region 0: I/O ports at 3fd3000f000 [size=8]
> Region 1: I/O ports at 3fd3000f010 [size=4]
> Region 2: I/O ports at 3fd3000f020 [size=8]
> Region 3: I/O ports at 3fd3000f030 [size=4]
> Region 4: I/O ports at 3fd3000f040 [size=16]
> Region 5: I/O ports at 3fd30000000 [size=16]
> 00: ad 10 05 01 41 01 80 02 05 8f 01 01 08 48 80 00
> 10: 01 f0 00 00 11 f0 00 00 21 f0 00 00 31 f0 00 00
> 20: 41 f0 00 00 01 00 00 00 00 00 00 00 00 00 00 00
Well, BAR5 is indeed 0.
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 56 01 02 28
> 40: b3 08 ff 00 09 09 00 00 09 09 00 00 09 09 00 00
> 50: 09 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 70: 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 00 00
> 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
> name "ide"
> linux,phandle 00d5cdc0 (14011840)
> assigned-addresses 81001910 00000000 0000f000 00000000 00000008 81001914
> 00000000 0000f010 00000000 00000004 81001918 00000000
> 0000f020 00000000 00000008 8100191c 00000000 0000f030
> 00000000 00000004 81001920 00000000 0000f040 00000000
> 00000010 81001924 00000000 00000000 00000000 00000010
Yeah, the device tree has 0 for BAR5 too...
WBR, Sergei
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: pata_sl82c105 can not reserve IO region
@ 2006-12-01 19:05 ` Sergei Shtylyov
0 siblings, 0 replies; 95+ messages in thread
From: Sergei Shtylyov @ 2006-12-01 19:05 UTC (permalink / raw)
To: Olaf Hering; +Cc: linux-ide, Alan, linuxppc-dev
Olaf Hering wrote:
>>The printk in pci_request_region has 'bar + 1', so 6 should be possible
>>if i becomes 5.
> Does the IO region of the last bar look correct?
I'd say it looks suspicious since it's not adjacent to all the other
regions... In fact, after looking at your /proc/ioports/ I can say that the
BAR is actually unassigned and its *actual* value is 0 which the driver may
not like (the ones that lspci show are the physical memory addresses not the
actual I/O space addresses in this case). That's why the reservation fails.
> 00:03.1 IDE interface: Symphony Labs SL82c105 (rev 05) (prog-if 8f [Master SecP SecO PriP PriO])
> 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 86
> Region 0: I/O ports at 3fd3000f000 [size=8]
> Region 1: I/O ports at 3fd3000f010 [size=4]
> Region 2: I/O ports at 3fd3000f020 [size=8]
> Region 3: I/O ports at 3fd3000f030 [size=4]
> Region 4: I/O ports at 3fd3000f040 [size=16]
> Region 5: I/O ports at 3fd30000000 [size=16]
> 00: ad 10 05 01 41 01 80 02 05 8f 01 01 08 48 80 00
> 10: 01 f0 00 00 11 f0 00 00 21 f0 00 00 31 f0 00 00
> 20: 41 f0 00 00 01 00 00 00 00 00 00 00 00 00 00 00
Well, BAR5 is indeed 0.
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 56 01 02 28
> 40: b3 08 ff 00 09 09 00 00 09 09 00 00 09 09 00 00
> 50: 09 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 70: 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 00 00
> 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
> name "ide"
> linux,phandle 00d5cdc0 (14011840)
> assigned-addresses 81001910 00000000 0000f000 00000000 00000008 81001914
> 00000000 0000f010 00000000 00000004 81001918 00000000
> 0000f020 00000000 00000008 8100191c 00000000 0000f030
> 00000000 00000004 81001920 00000000 0000f040 00000000
> 00000010 81001924 00000000 00000000 00000000 00000010
Yeah, the device tree has 0 for BAR5 too...
WBR, Sergei
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: pata_sl82c105 can not reserve IO region
2006-12-01 19:05 ` Sergei Shtylyov
@ 2006-12-01 21:53 ` Benjamin Herrenschmidt
-1 siblings, 0 replies; 95+ messages in thread
From: Benjamin Herrenschmidt @ 2006-12-01 21:53 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: Olaf Hering, linux-ide, Alan, linuxppc-dev
On Fri, 2006-12-01 at 22:05 +0300, Sergei Shtylyov wrote:
> Olaf Hering wrote:
>
> >>The printk in pci_request_region has 'bar + 1', so 6 should be possible
> >>if i becomes 5.
>
> > Does the IO region of the last bar look correct?
I think BAR 5 is unassigned by the firmware, though when OF does that,
it often means that an OF driver for that chip decided that the BAR
wasn't useful.
In fact, the driver doesn't actually use that BAR 5... Only 0 to 4
afaik.
I think the libata code shouldn't request the BARs it doesn't need or
that problem will hit us in other circumstances. It should only request
0 to 4 and let the drivers request 5 themselves if they need it.
Ben.
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: pata_sl82c105 can not reserve IO region
@ 2006-12-01 21:53 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 95+ messages in thread
From: Benjamin Herrenschmidt @ 2006-12-01 21:53 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linux-ide, Olaf Hering, Alan, linuxppc-dev
On Fri, 2006-12-01 at 22:05 +0300, Sergei Shtylyov wrote:
> Olaf Hering wrote:
>
> >>The printk in pci_request_region has 'bar + 1', so 6 should be possible
> >>if i becomes 5.
>
> > Does the IO region of the last bar look correct?
I think BAR 5 is unassigned by the firmware, though when OF does that,
it often means that an OF driver for that chip decided that the BAR
wasn't useful.
In fact, the driver doesn't actually use that BAR 5... Only 0 to 4
afaik.
I think the libata code shouldn't request the BARs it doesn't need or
that problem will hit us in other circumstances. It should only request
0 to 4 and let the drivers request 5 themselves if they need it.
Ben.
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: pata_sl82c105 can not reserve IO region
2006-12-01 21:53 ` Benjamin Herrenschmidt
@ 2006-12-01 22:15 ` Alan
-1 siblings, 0 replies; 95+ messages in thread
From: Alan @ 2006-12-01 22:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Sergei Shtylyov, Olaf Hering, linux-ide, linuxppc-dev
On Sat, 02 Dec 2006 08:53:49 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> In fact, the driver doesn't actually use that BAR 5... Only 0 to 4
> afaik.
>
> I think the libata code shouldn't request the BARs it doesn't need or
> that problem will hit us in other circumstances. It should only request
> 0 to 4 and let the drivers request 5 themselves if they need it.
I don't think that is the problem. pci_request_regions() handles all
this internally. It is incorrect for me to not request BAR 5
if present as nobody else should use that resource with my driver loaded.
The underlying problem appears to be that PPC64 isn't setting up the
resources properly (at least as viewed by the pci core code). If a
resource is not set up then pci_request_resource() correctly handles
it .. except on PPC64. You have a resource at zero with a length and
type. PPC64 is not reporting to the upper layers that the resource was
not allocated. It is reporting that the resource *was* allocated, and at a
bogus address of zero.
If you trust the firmware that is fine, but you need to report the truth,
at which point pci_request_resources() will work correctly.
Alan
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: pata_sl82c105 can not reserve IO region
@ 2006-12-01 22:15 ` Alan
0 siblings, 0 replies; 95+ messages in thread
From: Alan @ 2006-12-01 22:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linux-ide, Olaf Hering, linuxppc-dev
On Sat, 02 Dec 2006 08:53:49 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> In fact, the driver doesn't actually use that BAR 5... Only 0 to 4
> afaik.
>
> I think the libata code shouldn't request the BARs it doesn't need or
> that problem will hit us in other circumstances. It should only request
> 0 to 4 and let the drivers request 5 themselves if they need it.
I don't think that is the problem. pci_request_regions() handles all
this internally. It is incorrect for me to not request BAR 5
if present as nobody else should use that resource with my driver loaded.
The underlying problem appears to be that PPC64 isn't setting up the
resources properly (at least as viewed by the pci core code). If a
resource is not set up then pci_request_resource() correctly handles
it .. except on PPC64. You have a resource at zero with a length and
type. PPC64 is not reporting to the upper layers that the resource was
not allocated. It is reporting that the resource *was* allocated, and at a
bogus address of zero.
If you trust the firmware that is fine, but you need to report the truth,
at which point pci_request_resources() will work correctly.
Alan
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: pata_sl82c105 can not reserve IO region
2006-12-01 22:15 ` Alan
@ 2006-12-01 22:19 ` Benjamin Herrenschmidt
-1 siblings, 0 replies; 95+ messages in thread
From: Benjamin Herrenschmidt @ 2006-12-01 22:19 UTC (permalink / raw)
To: Alan; +Cc: Sergei Shtylyov, Olaf Hering, linux-ide, linuxppc-dev
> I don't think that is the problem. pci_request_regions() handles all
> this internally. It is incorrect for me to not request BAR 5
> if present as nobody else should use that resource with my driver loaded.
>
> The underlying problem appears to be that PPC64 isn't setting up the
> resources properly (at least as viewed by the pci core code). If a
> resource is not set up then pci_request_resource() correctly handles
> it .. except on PPC64. You have a resource at zero with a length and
> type. PPC64 is not reporting to the upper layers that the resource was
> not allocated. It is reporting that the resource *was* allocated, and at a
> bogus address of zero.
>
> If you trust the firmware that is fine, but you need to report the truth,
> at which point pci_request_resources() will work correctly.
We don't have a choice but to trust the firmware on those machines. We
can't assign things ourselves on most of them for various reasons (in
many cases, the hypervisor won't let us).
So you suggest that I clear resource->flags in that case ?
I think part of the problem is a firmware bug in that the firmware data
actually decodes to BAR 5 is assigned to address 0 ... I suppose we can
consider that address 0 is never valid on those machines and consider
that as unassigned but it's a bit dodgy.. Or maybe a PCI quirk in the
pSeries code would be best.
Ben.
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: pata_sl82c105 can not reserve IO region
@ 2006-12-01 22:19 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 95+ messages in thread
From: Benjamin Herrenschmidt @ 2006-12-01 22:19 UTC (permalink / raw)
To: Alan; +Cc: linux-ide, Olaf Hering, linuxppc-dev
> I don't think that is the problem. pci_request_regions() handles all
> this internally. It is incorrect for me to not request BAR 5
> if present as nobody else should use that resource with my driver loaded.
>
> The underlying problem appears to be that PPC64 isn't setting up the
> resources properly (at least as viewed by the pci core code). If a
> resource is not set up then pci_request_resource() correctly handles
> it .. except on PPC64. You have a resource at zero with a length and
> type. PPC64 is not reporting to the upper layers that the resource was
> not allocated. It is reporting that the resource *was* allocated, and at a
> bogus address of zero.
>
> If you trust the firmware that is fine, but you need to report the truth,
> at which point pci_request_resources() will work correctly.
We don't have a choice but to trust the firmware on those machines. We
can't assign things ourselves on most of them for various reasons (in
many cases, the hypervisor won't let us).
So you suggest that I clear resource->flags in that case ?
I think part of the problem is a firmware bug in that the firmware data
actually decodes to BAR 5 is assigned to address 0 ... I suppose we can
consider that address 0 is never valid on those machines and consider
that as unassigned but it's a bit dodgy.. Or maybe a PCI quirk in the
pSeries code would be best.
Ben.
^ permalink raw reply [flat|nested] 95+ messages in thread
* U-Boot allocating PCI I/O space from 0 (Was: pata_sl82c105 can not reserve IO region)
2006-12-01 22:19 ` Benjamin Herrenschmidt
@ 2006-12-02 14:36 ` Sergei Shtylyov
-1 siblings, 0 replies; 95+ messages in thread
From: Sergei Shtylyov @ 2006-12-02 14:36 UTC (permalink / raw)
To: u-boot-users; +Cc: linuxppc-embedded
Hello.
Benjamin Herrenschmidt wrote:
>>I don't think that is the problem. pci_request_regions() handles all
>>this internally. It is incorrect for me to not request BAR 5
>>if present as nobody else should use that resource with my driver loaded.
>>The underlying problem appears to be that PPC64 isn't setting up the
>>resources properly (at least as viewed by the pci core code). If a
>>resource is not set up then pci_request_resource() correctly handles
>>it .. except on PPC64. You have a resource at zero with a length and
>>type. PPC64 is not reporting to the upper layers that the resource was
>>not allocated. It is reporting that the resource *was* allocated, and at a
>>bogus address of zero.
>>If you trust the firmware that is fine, but you need to report the truth,
>>at which point pci_request_resources() will work correctly.
> We don't have a choice but to trust the firmware on those machines. We
> can't assign things ourselves on most of them for various reasons (in
> many cases, the hypervisor won't let us).
> So you suggest that I clear resource->flags in that case ?
> I think part of the problem is a firmware bug in that the firmware data
> actually decodes to BAR 5 is assigned to address 0 ... I suppose we can
> consider that address 0 is never valid on those machines and consider
> that as unassigned but it's a bit dodgy.. Or maybe a PCI quirk in the
> pSeries code would be best.
Well, I'm having a very related issue with the U-Boot on MPC85xx: recently
I've noticed that it started allocating PCI I/O space from 0 (while the older
versions started from 0x1000). The IDE core can't tolerate this, giving me
such messages on bootup:
PDC20269: inconsistent baseregs (BIOS) for port 0, skipping
when I have Promise Ultra133TX2 card inserted into PCI alone. I've looked thru
the U-Boot sources and commit history but failed to locate the change that led
to this...
WBR, Sergei
^ permalink raw reply [flat|nested] 95+ messages in thread
* [U-Boot-Users] U-Boot allocating PCI I/O space from 0 (Was: pata_sl82c105 can not reserve IO region)
@ 2006-12-02 14:36 ` Sergei Shtylyov
0 siblings, 0 replies; 95+ messages in thread
From: Sergei Shtylyov @ 2006-12-02 14:36 UTC (permalink / raw)
To: u-boot
Hello.
Benjamin Herrenschmidt wrote:
>>I don't think that is the problem. pci_request_regions() handles all
>>this internally. It is incorrect for me to not request BAR 5
>>if present as nobody else should use that resource with my driver loaded.
>>The underlying problem appears to be that PPC64 isn't setting up the
>>resources properly (at least as viewed by the pci core code). If a
>>resource is not set up then pci_request_resource() correctly handles
>>it .. except on PPC64. You have a resource at zero with a length and
>>type. PPC64 is not reporting to the upper layers that the resource was
>>not allocated. It is reporting that the resource *was* allocated, and at a
>>bogus address of zero.
>>If you trust the firmware that is fine, but you need to report the truth,
>>at which point pci_request_resources() will work correctly.
> We don't have a choice but to trust the firmware on those machines. We
> can't assign things ourselves on most of them for various reasons (in
> many cases, the hypervisor won't let us).
> So you suggest that I clear resource->flags in that case ?
> I think part of the problem is a firmware bug in that the firmware data
> actually decodes to BAR 5 is assigned to address 0 ... I suppose we can
> consider that address 0 is never valid on those machines and consider
> that as unassigned but it's a bit dodgy.. Or maybe a PCI quirk in the
> pSeries code would be best.
Well, I'm having a very related issue with the U-Boot on MPC85xx: recently
I've noticed that it started allocating PCI I/O space from 0 (while the older
versions started from 0x1000). The IDE core can't tolerate this, giving me
such messages on bootup:
PDC20269: inconsistent baseregs (BIOS) for port 0, skipping
when I have Promise Ultra133TX2 card inserted into PCI alone. I've looked thru
the U-Boot sources and commit history but failed to locate the change that led
to this...
WBR, Sergei
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: U-Boot allocating PCI I/O space from 0 (Was: pata_sl82c105 can not reserve IO region)
2006-12-02 14:36 ` [U-Boot-Users] " Sergei Shtylyov
@ 2006-12-02 16:33 ` Sergei Shtylyov
-1 siblings, 0 replies; 95+ messages in thread
From: Sergei Shtylyov @ 2006-12-02 16:33 UTC (permalink / raw)
To: u-boot-users; +Cc: linuxppc-embedded
Hello.
Sergei Shtylyov wrote:
> Well, I'm having a very related issue with the U-Boot on MPC85xx: recently
> I've noticed that it started allocating PCI I/O space from 0 (while the older
> versions started from 0x1000). The IDE core can't tolerate this, giving me
> such messages on bootup:
> PDC20269: inconsistent baseregs (BIOS) for port 0, skipping
> when I have Promise Ultra133TX2 card inserted into PCI alone. I've looked thru
> the U-Boot sources and commit history but failed to locate the change that led
> to this...
It's actually much worse than just that. When I also plug in some other
PCI card so Ultra133TX2 doesn't get the zero addresses anymore, I'm getting this:
eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin
<saw@saw.sw.com.sg> and others
eth3: Invalid EEPROM checksum 0xfffe, check settings before activating this
device!
eth3: OEM i82557/i82558 10/100 Ethernet, 00:00:00:00:FF:FF, IRQ 52.
[...]
PDC20269: 100% native mode on irq 51
ide2: BM-DMA at 0x0060-0x0067, BIOS settings: hde:pio, hdf:pio
PDC20269: simplex device: DMA disabled
ide3: PDC20269 Bus-Master DMA disabled (BIOS)
I've just verified that both these cards are working OK in x86 box
As for the simplex message, I've encountered this some months ago and it was
caused by invalid programming of the MPC85xx bridge PCI/X outbound translation
address register for the I/O space or at least by the non-zero value of the
bus I/O address in the "ranges" property of the bridge device node in the
device tree... I'm somewhat confused now since I know that the relevant U-Boot
code has been fixed but it looks like that made it only worse -- I was using
the custom patched version of U-Boot before which missed that fix:
http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commitdiff;h=97074ed9655309b64231bc2cee69fe85399f8055
WBR, Sergei
^ permalink raw reply [flat|nested] 95+ messages in thread
* [U-Boot-Users] U-Boot allocating PCI I/O space from 0 (Was: pata_sl82c105 can not reserve IO region)
@ 2006-12-02 16:33 ` Sergei Shtylyov
0 siblings, 0 replies; 95+ messages in thread
From: Sergei Shtylyov @ 2006-12-02 16:33 UTC (permalink / raw)
To: u-boot
Hello.
Sergei Shtylyov wrote:
> Well, I'm having a very related issue with the U-Boot on MPC85xx: recently
> I've noticed that it started allocating PCI I/O space from 0 (while the older
> versions started from 0x1000). The IDE core can't tolerate this, giving me
> such messages on bootup:
> PDC20269: inconsistent baseregs (BIOS) for port 0, skipping
> when I have Promise Ultra133TX2 card inserted into PCI alone. I've looked thru
> the U-Boot sources and commit history but failed to locate the change that led
> to this...
It's actually much worse than just that. When I also plug in some other
PCI card so Ultra133TX2 doesn't get the zero addresses anymore, I'm getting this:
eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin
<saw@saw.sw.com.sg> and others
eth3: Invalid EEPROM checksum 0xfffe, check settings before activating this
device!
eth3: OEM i82557/i82558 10/100 Ethernet, 00:00:00:00:FF:FF, IRQ 52.
[...]
PDC20269: 100% native mode on irq 51
ide2: BM-DMA at 0x0060-0x0067, BIOS settings: hde:pio, hdf:pio
PDC20269: simplex device: DMA disabled
ide3: PDC20269 Bus-Master DMA disabled (BIOS)
I've just verified that both these cards are working OK in x86 box
As for the simplex message, I've encountered this some months ago and it was
caused by invalid programming of the MPC85xx bridge PCI/X outbound translation
address register for the I/O space or at least by the non-zero value of the
bus I/O address in the "ranges" property of the bridge device node in the
device tree... I'm somewhat confused now since I know that the relevant U-Boot
code has been fixed but it looks like that made it only worse -- I was using
the custom patched version of U-Boot before which missed that fix:
http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commitdiff;h=97074ed9655309b64231bc2cee69fe85399f8055
WBR, Sergei
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: pata_sl82c105 can not reserve IO region
2006-11-30 16:52 pata_sl82c105 can not reserve IO region Olaf Hering
2006-11-30 17:10 ` Alan
@ 2006-12-03 17:12 ` Olaf Hering
2006-12-03 22:24 ` Olaf Hering
2006-12-03 23:07 ` Alan
2006-12-04 12:38 ` [PATCH] mark PCI resource with start 0 as unassigned Olaf Hering
2006-12-04 12:40 ` [PATCH] add delay around sl82c105_reset_engine calls Olaf Hering
3 siblings, 2 replies; 95+ messages in thread
From: Olaf Hering @ 2006-12-03 17:12 UTC (permalink / raw)
To: linux-ide, linuxppc-dev
On Thu, Nov 30, Olaf Hering wrote:
>
> pata_sl82c105 can be used on the ppc64 POWER4 system p610, p615 and p630
> for the onboard IDE CD drive. It could be also used for ppc32 Motorola
> PowerStack PReP systems.
>
> Unfortunately, it doesnt work for me on the p630:
>
> PCI: Enabling device: (0000:00:03.1), cmd 141
> PCI: Unable to reserve I/O region #6:10@0 for device 0000:00:03.1
> pata_sl82c105: probe of 0000:00:03.1 failed with error -16
I modified pci_request_regions to request only the first 5 regions.
Now the detection works, but access to the drive does not work:
[ 175.479288] PCI: Enabling device: (0000:00:03.1), cmd 141
[ 181.533396] ata1: PATA max MWDMA2 cmd 0xF000 ctl 0xF012 bmdma 0xF040 irq 86
[ 175.542281] scsi2 : pata_sl82c105
[ 175.879574] ata1.00: ATAPI, max UDMA/33
[ 176.055641] ata1.00: configured for MWDMA2
[ 176.065579] scsi 2:0:0:0: CD-ROM LG CD-ROM CRD-8484B 2.01 PQ: 0 ANSI: 5
[ 176.077138] sr0: scsi3-mmc drive: 48x/48x cd/rw xa/form2 cdda tray
[ 176.086020] Uniform CD-ROM driver Revision: 3.20
[ 176.094959] sr 2:0:0:0: Attached scsi CD-ROM sr0
[ 176.103932] sr 2:0:0:0: Attached scsi generic sg4 type 5
[ 194.947620] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
[ 194.947628] ata1.00: (BMDMA stat 0x41)
[ 194.947693] ata1.00: tag 0 cmd 0xa0 Emask 0x4 stat 0x40 err 0x0 (timeout)
[ 194.947714] ata1: soft resetting port
[ 195.448133] ata1.00: configured for MWDMA2
[ 195.448157] ata1: EH complete
[ 200.450116] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
[ 200.450124] ata1.00: (BMDMA stat 0x41)
[ 200.450132] ata1.00: tag 0 cmd 0xa0 Emask 0x4 stat 0x40 err 0x0 (timeout)
[ 200.450153] ata1: soft resetting port
[ 200.945670] ata1.00: configured for MWDMA2
[ 200.945695] ata1: EH complete
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: pata_sl82c105 can not reserve IO region
2006-12-03 17:12 ` Olaf Hering
@ 2006-12-03 22:24 ` Olaf Hering
2006-12-03 23:23 ` Alan
2006-12-03 23:07 ` Alan
1 sibling, 1 reply; 95+ messages in thread
From: Olaf Hering @ 2006-12-03 22:24 UTC (permalink / raw)
To: linux-ide, linuxppc-dev
On Sun, Dec 03, Olaf Hering wrote:
> [ 194.947620] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
> [ 194.947628] ata1.00: (BMDMA stat 0x41)
> [ 194.947693] ata1.00: tag 0 cmd 0xa0 Emask 0x4 stat 0x40 err 0x0 (timeout)
> [ 194.947714] ata1: soft resetting port
> [ 195.448133] ata1.00: configured for MWDMA2
> [ 195.448157] ata1: EH complete
> [ 200.450116] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
> [ 200.450124] ata1.00: (BMDMA stat 0x41)
> [ 200.450132] ata1.00: tag 0 cmd 0xa0 Emask 0x4 stat 0x40 err 0x0 (timeout)
> [ 200.450153] ata1: soft resetting port
> [ 200.945670] ata1.00: configured for MWDMA2
> [ 200.945695] ata1: EH complete
This change seems to fix it, only a single reset occurs. I think that
one is normal when a CD is in the drive during bootup, maybe it leaves
the drive in a confused state.
@@ -167,9 +175,13 @@ static void sl82c105_reset_engine(struct
struct pci_dev *pdev = to_pci_dev(ap->host->dev);
u16 val;
+ udelay(42);
pci_read_config_word(pdev, 0x7E, &val);
+ udelay(10);
pci_write_config_word(pdev, 0x7E, val | 4);
+ udelay(10);
pci_write_config_word(pdev, 0x7E, val & ~4);
+ udelay(42);
}
/**
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: pata_sl82c105 can not reserve IO region
2006-12-03 17:12 ` Olaf Hering
2006-12-03 22:24 ` Olaf Hering
@ 2006-12-03 23:07 ` Alan
1 sibling, 0 replies; 95+ messages in thread
From: Alan @ 2006-12-03 23:07 UTC (permalink / raw)
To: Olaf Hering; +Cc: linux-ide, linuxppc-dev
> I modified pci_request_regions to request only the first 5 regions.
> Now the detection works, but access to the drive does not work:
Some drives do that with the new EH code. Its ATAPI specific and I don't
know why. With the older libata it all works. It may also be a driver bug
but since it also pops up all over the place with the new EH code and not
the old its damn near impossible to debug any PATA problems that look
like this at the moment.
Alan
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: pata_sl82c105 can not reserve IO region
2006-12-03 22:24 ` Olaf Hering
@ 2006-12-03 23:23 ` Alan
2006-12-04 0:30 ` Olaf Hering
0 siblings, 1 reply; 95+ messages in thread
From: Alan @ 2006-12-03 23:23 UTC (permalink / raw)
To: Olaf Hering; +Cc: linux-ide, linuxppc-dev
On Sun, 3 Dec 2006 23:24:49 +0100 (MET)
Olaf Hering <olaf@aepfle.de> wrote:
> This change seems to fix it, only a single reset occurs. I think that
> one is normal when a CD is in the drive during bootup, maybe it leaves
> the drive in a confused state.
>
> @@ -167,9 +175,13 @@ static void sl82c105_reset_engine(struct
> struct pci_dev *pdev = to_pci_dev(ap->host->dev);
> u16 val;
>
> + udelay(42);
> pci_read_config_word(pdev, 0x7E, &val);
> + udelay(10);
> pci_write_config_word(pdev, 0x7E, val | 4);
> + udelay(10);
> pci_write_config_word(pdev, 0x7E, val & ~4);
> + udelay(42);
> }
Where do you get the delays from ? There is nothing in the documentation
or errata sheets I have here on that subject. Is this guesswork, divine
inspiration or an errata note I don't posess ?
In the absence of documented behaviour its seem to me much more likely
that the delay is actually either moving a race condition in the libata
code, or perhaps just allowing some time for the CD to "recover" in which
case it's perhaps a bit of a delay we need in libata. That would explain
why the old -> new change broke stuff.
Either way its most interesting it makes a difference.
Alan
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: pata_sl82c105 can not reserve IO region
2006-12-01 22:19 ` Benjamin Herrenschmidt
@ 2006-12-03 23:39 ` Alan
-1 siblings, 0 replies; 95+ messages in thread
From: Alan @ 2006-12-03 23:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Sergei Shtylyov, Olaf Hering, linux-ide, linuxppc-dev
On Sat, 02 Dec 2006 09:19:43 +1100
> We don't have a choice but to trust the firmware on those machines. We
> can't assign things ourselves on most of them for various reasons (in
> many cases, the hypervisor won't let us).
>
> So you suggest that I clear resource->flags in that case ?
That will do the trick yes.
> I think part of the problem is a firmware bug in that the firmware data
> actually decodes to BAR 5 is assigned to address 0 ... I suppose we can
> consider that address 0 is never valid on those machines and consider
> that as unassigned
The core PCI code already "knows" that zero in a resource_start() is
unassigned
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: pata_sl82c105 can not reserve IO region
@ 2006-12-03 23:39 ` Alan
0 siblings, 0 replies; 95+ messages in thread
From: Alan @ 2006-12-03 23:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linux-ide, Olaf Hering, linuxppc-dev
On Sat, 02 Dec 2006 09:19:43 +1100
> We don't have a choice but to trust the firmware on those machines. We
> can't assign things ourselves on most of them for various reasons (in
> many cases, the hypervisor won't let us).
>
> So you suggest that I clear resource->flags in that case ?
That will do the trick yes.
> I think part of the problem is a firmware bug in that the firmware data
> actually decodes to BAR 5 is assigned to address 0 ... I suppose we can
> consider that address 0 is never valid on those machines and consider
> that as unassigned
The core PCI code already "knows" that zero in a resource_start() is
unassigned
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: pata_sl82c105 can not reserve IO region
2006-12-03 23:23 ` Alan
@ 2006-12-04 0:30 ` Olaf Hering
2006-12-04 9:21 ` Olaf Hering
0 siblings, 1 reply; 95+ messages in thread
From: Olaf Hering @ 2006-12-04 0:30 UTC (permalink / raw)
To: Alan; +Cc: linux-ide, linuxppc-dev
On Sun, Dec 03, Alan wrote:
> On Sun, 3 Dec 2006 23:24:49 +0100 (MET)
> Olaf Hering <olaf@aepfle.de> wrote:
>
> > This change seems to fix it, only a single reset occurs. I think that
> > one is normal when a CD is in the drive during bootup, maybe it leaves
> > the drive in a confused state.
> >
> > @@ -167,9 +175,13 @@ static void sl82c105_reset_engine(struct
> > struct pci_dev *pdev = to_pci_dev(ap->host->dev);
> > u16 val;
> >
> > + udelay(42);
> > pci_read_config_word(pdev, 0x7E, &val);
> > + udelay(10);
> > pci_write_config_word(pdev, 0x7E, val | 4);
> > + udelay(10);
> > pci_write_config_word(pdev, 0x7E, val & ~4);
> > + udelay(42);
> > }
>
> Where do you get the delays from ? There is nothing in the documentation
> or errata sheets I have here on that subject. Is this guesswork, divine
> inspiration or an errata note I don't posess ?
Just guessing.
The udelay(10) calls can go, then it still works.
I moved the delays to the callers, which should have been equivalent,
but it failed again.
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: pata_sl82c105 can not reserve IO region
2006-12-04 0:30 ` Olaf Hering
@ 2006-12-04 9:21 ` Olaf Hering
0 siblings, 0 replies; 95+ messages in thread
From: Olaf Hering @ 2006-12-04 9:21 UTC (permalink / raw)
To: Alan; +Cc: linux-ide, linuxppc-dev
On Mon, Dec 04, Olaf Hering wrote:
> On Sun, Dec 03, Alan wrote:
>
> > On Sun, 3 Dec 2006 23:24:49 +0100 (MET)
> > Olaf Hering <olaf@aepfle.de> wrote:
> >
> > > This change seems to fix it, only a single reset occurs. I think that
> > > one is normal when a CD is in the drive during bootup, maybe it leaves
> > > the drive in a confused state.
> > >
> > > @@ -167,9 +175,13 @@ static void sl82c105_reset_engine(struct
> > > struct pci_dev *pdev = to_pci_dev(ap->host->dev);
> > > u16 val;
> > >
> > > + udelay(42);
> > > pci_read_config_word(pdev, 0x7E, &val);
> > > + udelay(10);
> > > pci_write_config_word(pdev, 0x7E, val | 4);
> > > + udelay(10);
> > > pci_write_config_word(pdev, 0x7E, val & ~4);
> > > + udelay(42);
> > > }
> >
> > Where do you get the delays from ? There is nothing in the documentation
> > or errata sheets I have here on that subject. Is this guesswork, divine
> > inspiration or an errata note I don't posess ?
>
> Just guessing.
> The udelay(10) calls can go, then it still works.
> I moved the delays to the callers, which should have been equivalent,
> but it failed again.
This patch gives still two resets during the first access, but the
access works ok afterwards:
Index: linux-2.6.19/drivers/ata/pata_sl82c105.c
===================================================================
--- linux-2.6.19.orig/drivers/ata/pata_sl82c105.c
+++ linux-2.6.19/drivers/ata/pata_sl82c105.c
@@ -187,7 +187,9 @@ static void sl82c105_bmdma_start(struct
{
struct ata_port *ap = qc->ap;
+ udelay(50);
sl82c105_reset_engine(ap);
+ udelay(50);
/* Set the clocks for DMA */
sl82c105_configure_dmamode(ap, qc->dev);
@@ -216,6 +218,7 @@ static void sl82c105_bmdma_stop(struct a
ata_bmdma_stop(qc);
sl82c105_reset_engine(ap);
+ udelay(50);
/* This will redo the initial setup of the DMA device to matching
PIO timings */
^ permalink raw reply [flat|nested] 95+ messages in thread
* [PATCH] mark PCI resource with start 0 as unassigned
2006-11-30 16:52 pata_sl82c105 can not reserve IO region Olaf Hering
2006-11-30 17:10 ` Alan
2006-12-03 17:12 ` Olaf Hering
@ 2006-12-04 12:38 ` Olaf Hering
2006-12-04 12:44 ` Segher Boessenkool
2006-12-04 12:47 ` Sergei Shtylyov
2006-12-04 12:40 ` [PATCH] add delay around sl82c105_reset_engine calls Olaf Hering
3 siblings, 2 replies; 95+ messages in thread
From: Olaf Hering @ 2006-12-04 12:38 UTC (permalink / raw)
To: linux-ide, linuxppc-dev
mark pci resources with start 0 as unassigned
libata calls pci_request_regions to claim bar 0 - 5
bar 5 has base 0.
Tested on a p630 in SMP mode with pata_sl82c105
00:03.1 IDE interface: Symphony Labs SL82c105 (rev 05) (prog-if 8f [Master SecP SecO PriP PriO])
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 86
Region 0: I/O ports at 3fd3000f000 [size=8]
Region 1: I/O ports at 3fd3000f010 [size=4]
Region 2: I/O ports at 3fd3000f020 [size=8]
Region 3: I/O ports at 3fd3000f030 [size=4]
Region 4: I/O ports at 3fd3000f040 [size=16]
Region 5: I/O ports at 3fd30000000 [size=16]
00: ad 10 05 01 41 01 80 02 05 8f 01 01 08 48 80 00
10: 01 f0 00 00 11 f0 00 00 21 f0 00 00 31 f0 00 00
20: 41 f0 00 00 01 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 56 01 02 28
40: b3 08 ff 00 09 09 00 00 09 09 00 00 09 09 00 00
50: 09 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
name "ide"
linux,phandle 00d5cdc0 (14011840)
assigned-addresses 81001910 00000000 0000f000 00000000 00000008 81001914
00000000 0000f010 00000000 00000004 81001918 00000000
0000f020 00000000 00000008 8100191c 00000000 0000f030
00000000 00000004 81001920 00000000 0000f040 00000000
00000010 81001924 00000000 00000000 00000000 00000010
interrupts 00000003
built-in
#size-cells 00000000
#address-cells 00000001
device_type "ide"
reg 00001900 00000000 00000000 00000000 00000000
41001910 00000000 00000000 00000000 00000008
41001914 00000000 00000000 00000000 00000004
41001918 00000000 00000000 00000000 00000008
4100191c 00000000 00000000 00000000 00000004
41001920 00000000 00000000 00000000 00000010
41001924 00000000 00000000 00000000 00000010
compatible "pci10ad,105"
"pciclass,01018f"
ibm,fw-slot-number 00000000
fast-back-to-back
devsel-speed 00000001
max-latency 00000028 (40)
min-grant 00000002
class-code 0001018f (65935)
revision-id 00000005
device-id 00000105 (261)
vendor-id 000010ad (4269)
ibm,loc-code "U0.1-P1/Q6"
Signed-off-by: Olaf Hering <olaf@aepfle.de>
---
arch/powerpc/kernel/pci_64.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/arch/powerpc/kernel/pci_64.c
+++ b/arch/powerpc/kernel/pci_64.c
@@ -1234,6 +1234,14 @@ static void __devinit fixup_resource(str
struct pci_controller *hose = pci_bus_to_host(dev->bus);
unsigned long start, end, mask, offset;
+ /*
+ * tell the core code that this ressource is unassigned
+ * fixes p630 winbond IDE with libata
+ */
+ if (res->start == 0) {
+ res->flags = 0;
+ return;
+ }
if (res->flags & IORESOURCE_IO) {
offset = (unsigned long)hose->io_base_virt - pci_io_base;
^ permalink raw reply [flat|nested] 95+ messages in thread
* [PATCH] add delay around sl82c105_reset_engine calls
2006-11-30 16:52 pata_sl82c105 can not reserve IO region Olaf Hering
` (2 preceding siblings ...)
2006-12-04 12:38 ` [PATCH] mark PCI resource with start 0 as unassigned Olaf Hering
@ 2006-12-04 12:40 ` Olaf Hering
2006-12-04 13:02 ` Alan
3 siblings, 1 reply; 95+ messages in thread
From: Olaf Hering @ 2006-12-04 12:40 UTC (permalink / raw)
To: linux-ide, linuxppc-dev
the hald media changed polling does really confuse things.
noone knows why the delays are needed, but they give us access to
the CD.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
---
drivers/scsi/pata_sl82c105.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/scsi/pata_sl82c105.c
+++ b/drivers/scsi/pata_sl82c105.c
@@ -187,7 +187,9 @@ static void sl82c105_bmdma_start(struct
{
struct ata_port *ap = qc->ap;
+ udelay(50);
sl82c105_reset_engine(ap);
+ udelay(50);
/* Set the clocks for DMA */
sl82c105_configure_dmamode(ap, qc->dev);
@@ -216,6 +218,7 @@ static void sl82c105_bmdma_stop(struct a
ata_bmdma_stop(qc);
sl82c105_reset_engine(ap);
+ udelay(50);
/* This will redo the initial setup of the DMA device to matching
PIO timings */
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH] mark PCI resource with start 0 as unassigned
2006-12-04 12:38 ` [PATCH] mark PCI resource with start 0 as unassigned Olaf Hering
@ 2006-12-04 12:44 ` Segher Boessenkool
2006-12-04 12:50 ` Sergei Shtylyov
2006-12-04 12:56 ` [PATCH] mark PCI resource with start 0 as unassigned Olaf Hering
2006-12-04 12:47 ` Sergei Shtylyov
1 sibling, 2 replies; 95+ messages in thread
From: Segher Boessenkool @ 2006-12-04 12:44 UTC (permalink / raw)
To: Olaf Hering; +Cc: linux-ide, linuxppc-dev
> --- a/arch/powerpc/kernel/pci_64.c
> +++ b/arch/powerpc/kernel/pci_64.c
> @@ -1234,6 +1234,14 @@ static void __devinit fixup_resource(str
> struct pci_controller *hose = pci_bus_to_host(dev->bus);
> unsigned long start, end, mask, offset;
>
> + /*
> + * tell the core code that this ressource is unassigned
> + * fixes p630 winbond IDE with libata
> + */
> + if (res->start == 0) {
> + res->flags = 0;
> + return;
> + }
> if (res->flags & IORESOURCE_IO) {
> offset = (unsigned long)hose->io_base_virt - pci_io_base;
Please make this run on pSeries only; on a PowerMac for
example, it's totally normal that the first PCI legacy I/O
BAR in the system gets assigned 0.
Segher
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH] mark PCI resource with start 0 as unassigned
2006-12-04 12:38 ` [PATCH] mark PCI resource with start 0 as unassigned Olaf Hering
2006-12-04 12:44 ` Segher Boessenkool
@ 2006-12-04 12:47 ` Sergei Shtylyov
1 sibling, 0 replies; 95+ messages in thread
From: Sergei Shtylyov @ 2006-12-04 12:47 UTC (permalink / raw)
To: Olaf Hering; +Cc: linux-ide, linuxppc-dev
Hello.
Olaf Hering wrote:
> mark pci resources with start 0 as unassigned
> libata calls pci_request_regions to claim bar 0 - 5
> bar 5 has base 0.
> Tested on a p630 in SMP mode with pata_sl82c105
[...]
> --- a/arch/powerpc/kernel/pci_64.c
> +++ b/arch/powerpc/kernel/pci_64.c
> @@ -1234,6 +1234,14 @@ static void __devinit fixup_resource(str
> struct pci_controller *hose = pci_bus_to_host(dev->bus);
> unsigned long start, end, mask, offset;
>
> + /*
> + * tell the core code that this ressource is unassigned
> + * fixes p630 winbond IDE with libata
> + */
> + if (res->start == 0) {
> + res->flags = 0;
Wouldn't it be better to set flags to IORESOURCE_UNSET to get it reassigned?
> + return;
> + }
> if (res->flags & IORESOURCE_IO) {
> offset = (unsigned long)hose->io_base_virt - pci_io_base;
>
WBR, Sergei
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH] mark PCI resource with start 0 as unassigned
2006-12-04 12:44 ` Segher Boessenkool
@ 2006-12-04 12:50 ` Sergei Shtylyov
2006-12-04 12:56 ` [PATCH] mark PCI resource with start 0 as unassigned Olaf Hering
1 sibling, 0 replies; 95+ messages in thread
From: Sergei Shtylyov @ 2006-12-04 12:50 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Olaf Hering, linux-ide, linuxppc-dev
Hello.
Segher Boessenkool wrote:
>>--- a/arch/powerpc/kernel/pci_64.c
>>+++ b/arch/powerpc/kernel/pci_64.c
>>@@ -1234,6 +1234,14 @@ static void __devinit fixup_resource(str
>> struct pci_controller *hose = pci_bus_to_host(dev->bus);
>> unsigned long start, end, mask, offset;
>>
>>+ /*
>>+ * tell the core code that this ressource is unassigned
>>+ * fixes p630 winbond IDE with libata
>>+ */
>>+ if (res->start == 0) {
>>+ res->flags = 0;
>>+ return;
>>+ }
>> if (res->flags & IORESOURCE_IO) {
>> offset = (unsigned long)hose->io_base_virt - pci_io_base;
>
>
> Please make this run on pSeries only; on a PowerMac for
> example, it's totally normal that the first PCI legacy I/O
> BAR in the system gets assigned 0.
What do you mean by legacy I/O BAR? If you mean IDE controller, that would
drive IDE core mad like this:
W82C105_IDE: inconsistent baseregs (BIOS) for port 0, skipping
> Segher
WBR, Sergei
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH] mark PCI resource with start 0 as unassigned
@ 2006-12-04 12:50 ` Sergei Shtylyov
0 siblings, 0 replies; 95+ messages in thread
From: Sergei Shtylyov @ 2006-12-04 12:50 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linux-ide, Olaf Hering, linuxppc-dev
Hello.
Segher Boessenkool wrote:
>>--- a/arch/powerpc/kernel/pci_64.c
>>+++ b/arch/powerpc/kernel/pci_64.c
>>@@ -1234,6 +1234,14 @@ static void __devinit fixup_resource(str
>> struct pci_controller *hose = pci_bus_to_host(dev->bus);
>> unsigned long start, end, mask, offset;
>>
>>+ /*
>>+ * tell the core code that this ressource is unassigned
>>+ * fixes p630 winbond IDE with libata
>>+ */
>>+ if (res->start == 0) {
>>+ res->flags = 0;
>>+ return;
>>+ }
>> if (res->flags & IORESOURCE_IO) {
>> offset = (unsigned long)hose->io_base_virt - pci_io_base;
>
>
> Please make this run on pSeries only; on a PowerMac for
> example, it's totally normal that the first PCI legacy I/O
> BAR in the system gets assigned 0.
What do you mean by legacy I/O BAR? If you mean IDE controller, that would
drive IDE core mad like this:
W82C105_IDE: inconsistent baseregs (BIOS) for port 0, skipping
> Segher
WBR, Sergei
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH] mark PCI resource with start 0 as unassigned
2006-12-04 12:50 ` Sergei Shtylyov
@ 2006-12-04 12:54 ` Segher Boessenkool
-1 siblings, 0 replies; 95+ messages in thread
From: Segher Boessenkool @ 2006-12-04 12:54 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: Olaf Hering, linux-ide, linuxppc-dev
>> Please make this run on pSeries only; on a PowerMac for
>> example, it's totally normal that the first PCI legacy I/O
>> BAR in the system gets assigned 0.
>
> What do you mean by legacy I/O BAR?
Any PCI BAR with bits 1:0 == 0b01.
> If you mean IDE controller, that would drive IDE core mad like this:
>
> W82C105_IDE: inconsistent baseregs (BIOS) for port 0, skipping
So that needs fixing too, then.
Segher
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH] mark PCI resource with start 0 as unassigned
@ 2006-12-04 12:54 ` Segher Boessenkool
0 siblings, 0 replies; 95+ messages in thread
From: Segher Boessenkool @ 2006-12-04 12:54 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linux-ide, Olaf Hering, linuxppc-dev
>> Please make this run on pSeries only; on a PowerMac for
>> example, it's totally normal that the first PCI legacy I/O
>> BAR in the system gets assigned 0.
>
> What do you mean by legacy I/O BAR?
Any PCI BAR with bits 1:0 == 0b01.
> If you mean IDE controller, that would drive IDE core mad like this:
>
> W82C105_IDE: inconsistent baseregs (BIOS) for port 0, skipping
So that needs fixing too, then.
Segher
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH] mark PCI resource with start 0 as unassigned
2006-12-04 12:44 ` Segher Boessenkool
2006-12-04 12:50 ` Sergei Shtylyov
@ 2006-12-04 12:56 ` Olaf Hering
2006-12-04 13:05 ` Segher Boessenkool
1 sibling, 1 reply; 95+ messages in thread
From: Olaf Hering @ 2006-12-04 12:56 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linux-ide, linuxppc-dev
On Mon, Dec 04, Segher Boessenkool wrote:
> >--- a/arch/powerpc/kernel/pci_64.c
> >+++ b/arch/powerpc/kernel/pci_64.c
> >@@ -1234,6 +1234,14 @@ static void __devinit fixup_resource(str
> > struct pci_controller *hose = pci_bus_to_host(dev->bus);
> > unsigned long start, end, mask, offset;
> >
> >+ /*
> >+ * tell the core code that this ressource is unassigned
> >+ * fixes p630 winbond IDE with libata
> >+ */
> >+ if (res->start == 0) {
> >+ res->flags = 0;
> >+ return;
> >+ }
> > if (res->flags & IORESOURCE_IO) {
> > offset = (unsigned long)hose->io_base_virt - pci_io_base;
>
> Please make this run on pSeries only; on a PowerMac for
I could just match for winbond an start == 0.
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH] add delay around sl82c105_reset_engine calls
2006-12-04 12:40 ` [PATCH] add delay around sl82c105_reset_engine calls Olaf Hering
@ 2006-12-04 13:02 ` Alan
2006-12-04 13:12 ` Olaf Hering
2007-01-04 6:42 ` Olaf Hering
0 siblings, 2 replies; 95+ messages in thread
From: Alan @ 2006-12-04 13:02 UTC (permalink / raw)
To: Olaf Hering; +Cc: linux-ide, linuxppc-dev
On Mon, 4 Dec 2006 13:40:26 +0100 (MET)
Olaf Hering <olaf@aepfle.de> wrote:
>
>
> the hald media changed polling does really confuse things.
> noone knows why the delays are needed, but they give us access to
> the CD.
Can you tell me what happens if you completely pull the reset out of the
dma_end function. Do you still need delays then.
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH] mark PCI resource with start 0 as unassigned
2006-12-04 12:56 ` [PATCH] mark PCI resource with start 0 as unassigned Olaf Hering
@ 2006-12-04 13:05 ` Segher Boessenkool
0 siblings, 0 replies; 95+ messages in thread
From: Segher Boessenkool @ 2006-12-04 13:05 UTC (permalink / raw)
To: Olaf Hering; +Cc: linux-ide, linuxppc-dev
>>> --- a/arch/powerpc/kernel/pci_64.c
>>> +++ b/arch/powerpc/kernel/pci_64.c
>>> @@ -1234,6 +1234,14 @@ static void __devinit fixup_resource(str
>>> struct pci_controller *hose = pci_bus_to_host(dev->bus);
>>> unsigned long start, end, mask, offset;
>>>
>>> + /*
>>> + * tell the core code that this ressource is unassigned
>>> + * fixes p630 winbond IDE with libata
>>> + */
>>> + if (res->start == 0) {
>>> + res->flags = 0;
>>> + return;
>>> + }
>>> if (res->flags & IORESOURCE_IO) {
>>> offset = (unsigned long)hose->io_base_virt - pci_io_base;
>>
>> Please make this run on pSeries only; on a PowerMac for
>
> I could just match for winbond an start == 0.
Why not fix it properly? The "0 means unassigned" thing is
something this specific firmware does, it is not a standard
or anything, and certainly not a property of the winbond
hardware (it _will_ react to legacy I/O at address 0).
So make this new code only run when this firmware is used,
too (perhaps do a check in prom_init and remove this BAR
from the assigned addresses property?)
Segher
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH] mark PCI resource with start 0 as unassigned
2006-12-04 12:54 ` Segher Boessenkool
@ 2006-12-04 13:08 ` Sergei Shtylyov
-1 siblings, 0 replies; 95+ messages in thread
From: Sergei Shtylyov @ 2006-12-04 13:08 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Olaf Hering, linux-ide, linuxppc-dev
Hello.
Segher Boessenkool wrote:
>>> Please make this run on pSeries only; on a PowerMac for
>>> example, it's totally normal that the first PCI legacy I/O
>>> BAR in the system gets assigned 0.
>> What do you mean by legacy I/O BAR?
> Any PCI BAR with bits 1:0 == 0b01.
>> If you mean IDE controller, that would drive IDE core mad like this:
>>
>> W82C105_IDE: inconsistent baseregs (BIOS) for port 0, skipping
> So that needs fixing too, then.
I'd agree here, that check in the IDE code seems like being too x86
specific. I'm having issues with it as well on MPC85xx/U-Boot...
> Segher
WBR, Sergei
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH] mark PCI resource with start 0 as unassigned
@ 2006-12-04 13:08 ` Sergei Shtylyov
0 siblings, 0 replies; 95+ messages in thread
From: Sergei Shtylyov @ 2006-12-04 13:08 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linux-ide, Olaf Hering, linuxppc-dev
Hello.
Segher Boessenkool wrote:
>>> Please make this run on pSeries only; on a PowerMac for
>>> example, it's totally normal that the first PCI legacy I/O
>>> BAR in the system gets assigned 0.
>> What do you mean by legacy I/O BAR?
> Any PCI BAR with bits 1:0 == 0b01.
>> If you mean IDE controller, that would drive IDE core mad like this:
>>
>> W82C105_IDE: inconsistent baseregs (BIOS) for port 0, skipping
> So that needs fixing too, then.
I'd agree here, that check in the IDE code seems like being too x86
specific. I'm having issues with it as well on MPC85xx/U-Boot...
> Segher
WBR, Sergei
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH] add delay around sl82c105_reset_engine calls
2006-12-04 13:02 ` Alan
@ 2006-12-04 13:12 ` Olaf Hering
2007-01-04 6:42 ` Olaf Hering
1 sibling, 0 replies; 95+ messages in thread
From: Olaf Hering @ 2006-12-04 13:12 UTC (permalink / raw)
To: Alan; +Cc: linux-ide, linuxppc-dev
On Mon, Dec 04, Alan wrote:
> On Mon, 4 Dec 2006 13:40:26 +0100 (MET)
> Olaf Hering <olaf@aepfle.de> wrote:
>
> >
> >
> > the hald media changed polling does really confuse things.
> > noone knows why the delays are needed, but they give us access to
> > the CD.
>
> Can you tell me what happens if you completely pull the reset out of the
> dma_end function. Do you still need delays then.
Did you mean like this?
@@ -215,7 +217,10 @@ static void sl82c105_bmdma_stop(struct a
struct ata_port *ap = qc->ap;
ata_bmdma_stop(qc);
+#if 0
sl82c105_reset_engine(ap);
+ udelay(50);
+#endif
/* This will redo the initial setup of the DMA device to matching
PIO timings */
[ 315.923917] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
[ 315.923927] ata1.00: (BMDMA stat 0x41)
[ 315.923935] ata1.00: tag 0 cmd 0xa0 Emask 0x4 stat 0x40 err 0x0 (timeout)
[ 315.924039] ata1: soft resetting port
[ 346.243816] ata1.00: qc timeout (cmd 0xa1)
[ 346.243829] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[ 346.243882] ata1.00: revalidation failed (errno=-5)
[ 346.243891] ata1: failed to recover some devices, retrying in 5 secs
[ 351.253802] ata1: soft resetting port
[ 381.573813] ata1.00: qc timeout (cmd 0xa1)
[ 381.573823] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[ 381.573876] ata1.00: revalidation failed (errno=-5)
[ 381.573884] ata1: failed to recover some devices, retrying in 5 secs
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH] mark PCI resource with start 0 as unassigned
2006-12-04 13:08 ` Sergei Shtylyov
(?)
@ 2006-12-04 13:21 ` Alan
2006-12-04 13:25 ` Segher Boessenkool
2006-12-04 13:27 ` Sergei Shtylyov
-1 siblings, 2 replies; 95+ messages in thread
From: Alan @ 2006-12-04 13:21 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linux-ide, Olaf Hering, linuxppc-dev
On Mon, 04 Dec 2006 16:08:46 +0300
Sergei Shtylyov <sshtylyov@ru.mvista.com> wrote:
> >> W82C105_IDE: inconsistent baseregs (BIOS) for port 0, skipping
> > So that needs fixing too, then.
Both PCI core and IDE interpret a zero length resource as unassigned.
That is probably better than clearing the flags in retrospect.
> I'd agree here, that check in the IDE code seems like being too x86
> specific. I'm having issues with it as well on MPC85xx/U-Boot...
setup-pci is for SFF8038i devices. It therefore knows that for assigned
resources they must be I/O. It also assumes that zero is not a valid I/O
port just like zero is not a valid IRQ. Stick a real IDE resource at zero
and drivers/ide can't cope.
Alan
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH] mark PCI resource with start 0 as unassigned
2006-12-04 13:21 ` Alan
@ 2006-12-04 13:25 ` Segher Boessenkool
2006-12-04 13:27 ` Sergei Shtylyov
1 sibling, 0 replies; 95+ messages in thread
From: Segher Boessenkool @ 2006-12-04 13:25 UTC (permalink / raw)
To: Alan; +Cc: Sergei Shtylyov, Olaf Hering, linux-ide, linuxppc-dev
> setup-pci is for SFF8038i devices. It therefore knows that for
> assigned
> resources they must be I/O. It also assumes that zero is not a
> valid I/O
> port just like zero is not a valid IRQ. Stick a real IDE resource
> at zero
> and drivers/ide can't cope.
But 0 _is_ a valid PCI I/O address. Do we now have to start
using "virtual I/O addresses", analogue to the IRQ situation,
or can these bad assumptions be fixed instead?
Segher
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH] mark PCI resource with start 0 as unassigned
@ 2006-12-04 13:25 ` Segher Boessenkool
0 siblings, 0 replies; 95+ messages in thread
From: Segher Boessenkool @ 2006-12-04 13:25 UTC (permalink / raw)
To: Alan; +Cc: linux-ide, Olaf Hering, linuxppc-dev
> setup-pci is for SFF8038i devices. It therefore knows that for
> assigned
> resources they must be I/O. It also assumes that zero is not a
> valid I/O
> port just like zero is not a valid IRQ. Stick a real IDE resource
> at zero
> and drivers/ide can't cope.
But 0 _is_ a valid PCI I/O address. Do we now have to start
using "virtual I/O addresses", analogue to the IRQ situation,
or can these bad assumptions be fixed instead?
Segher
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH] mark PCI resource with start 0 as unassigned
2006-12-04 13:21 ` Alan
@ 2006-12-04 13:27 ` Sergei Shtylyov
2006-12-04 13:27 ` Sergei Shtylyov
1 sibling, 0 replies; 95+ messages in thread
From: Sergei Shtylyov @ 2006-12-04 13:27 UTC (permalink / raw)
To: Alan; +Cc: Segher Boessenkool, Olaf Hering, linux-ide, linuxppc-dev
Hello.
Alan wrote:
>>>>W82C105_IDE: inconsistent baseregs (BIOS) for port 0, skipping
>>>So that needs fixing too, then.
> Both PCI core and IDE interpret a zero length resource as unassigned.
This is not about 0-length resource, this is about 0-address. Look at
ide_hwif_confiure() in drivers/ide/setup-pci.c...
> That is probably better than clearing the flags in retrospect.
>> I'd agree here, that check in the IDE code seems like being too x86
>>specific. I'm having issues with it as well on MPC85xx/U-Boot...
> setup-pci is for SFF8038i devices. It therefore knows that for assigned
> resources they must be I/O. It also assumes that zero is not a valid I/O
> port just like zero is not a valid IRQ.
You should know that the IRQ assumption is *not* true even for x86 since
IRQ0 is and has always been a perfectly valid IRQ (used by PIT).
> Stick a real IDE resource at zero
> and drivers/ide can't cope.
Yeah, I've noticed. Unfortunately, a lot of PPC platforms (at least) are
doing exactly this...
> Alan
WBR, Sergei
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH] mark PCI resource with start 0 as unassigned
@ 2006-12-04 13:27 ` Sergei Shtylyov
0 siblings, 0 replies; 95+ messages in thread
From: Sergei Shtylyov @ 2006-12-04 13:27 UTC (permalink / raw)
To: Alan; +Cc: linux-ide, Olaf Hering, linuxppc-dev
Hello.
Alan wrote:
>>>>W82C105_IDE: inconsistent baseregs (BIOS) for port 0, skipping
>>>So that needs fixing too, then.
> Both PCI core and IDE interpret a zero length resource as unassigned.
This is not about 0-length resource, this is about 0-address. Look at
ide_hwif_confiure() in drivers/ide/setup-pci.c...
> That is probably better than clearing the flags in retrospect.
>> I'd agree here, that check in the IDE code seems like being too x86
>>specific. I'm having issues with it as well on MPC85xx/U-Boot...
> setup-pci is for SFF8038i devices. It therefore knows that for assigned
> resources they must be I/O. It also assumes that zero is not a valid I/O
> port just like zero is not a valid IRQ.
You should know that the IRQ assumption is *not* true even for x86 since
IRQ0 is and has always been a perfectly valid IRQ (used by PIT).
> Stick a real IDE resource at zero
> and drivers/ide can't cope.
Yeah, I've noticed. Unfortunately, a lot of PPC platforms (at least) are
doing exactly this...
> Alan
WBR, Sergei
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH] mark PCI resource with start 0 as unassigned
2006-12-04 13:25 ` Segher Boessenkool
(?)
@ 2006-12-04 14:15 ` Alan
-1 siblings, 0 replies; 95+ messages in thread
From: Alan @ 2006-12-04 14:15 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linux-ide, Olaf Hering, linuxppc-dev
On Mon, 4 Dec 2006 14:25:04 +0100
Segher Boessenkool <segher@kernel.crashing.org> wrote:
> But 0 _is_ a valid PCI I/O address. Do we now have to start
> using "virtual I/O addresses", analogue to the IRQ situation,
> or can these bad assumptions be fixed instead?
Send patches to Bartlomiej now he is back in circulation.
Alan
^ permalink raw reply [flat|nested] 95+ messages in thread
* What is the correct way to indicate an unassigned PCI resource ?
2006-12-04 13:27 ` Sergei Shtylyov
(?)
@ 2006-12-04 14:22 ` Alan
2006-12-04 14:34 ` Sergei Shtylyov
2006-12-05 4:41 ` Benjamin Herrenschmidt
-1 siblings, 2 replies; 95+ messages in thread
From: Alan @ 2006-12-04 14:22 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: Olaf Hering, linuxppc-dev, greg, linux-ide, linux-pci
On Mon, 04 Dec 2006 16:27:47 +0300
Sergei Shtylyov <sshtylyov@ru.mvista.com> wrote:
> > Both PCI core and IDE interpret a zero length resource as unassigned.
>
> This is not about 0-length resource, this is about 0-address. Look at
> ide_hwif_confiure() in drivers/ide/setup-pci.c...
The discussion I was having was about sl82cxx and handling unassigned
resources. The zero address isn't relevant to that.
> You should know that the IRQ assumption is *not* true even for x86 since
> IRQ0 is and has always been a perfectly valid IRQ (used by PIT).
Please see previous million recyclings of that discussion and Linus
answer.
> > Stick a real IDE resource at zero
> > and drivers/ide can't cope.
>
> Yeah, I've noticed. Unfortunately, a lot of PPC platforms (at least) are
> doing exactly this...
The checks need pushing upwards and removing from their current place -
the pci layer should check the resource length, the isa pnp should I
believe check for zero address etc.
libata makes a similar assumption in ata_resources_present() as someone
(GregKH ???) needs to define what the proper way to encode "resource not
allocated" into the PCI resources should be. If someone on the PCI list
(cc'd) or Greg can give a definitive answer then we can go fix the
offenders now.
Alan
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: What is the correct way to indicate an unassigned PCI resource ?
2006-12-04 14:22 ` What is the correct way to indicate an unassigned PCI resource ? Alan
@ 2006-12-04 14:34 ` Sergei Shtylyov
2006-12-05 4:41 ` Benjamin Herrenschmidt
1 sibling, 0 replies; 95+ messages in thread
From: Sergei Shtylyov @ 2006-12-04 14:34 UTC (permalink / raw)
To: Alan
Cc: Segher Boessenkool, Olaf Hering, linux-ide, linuxppc-dev, greg,
linux-pci
Hello.
Alan wrote:
>>>Both PCI core and IDE interpret a zero length resource as unassigned.
>> This is not about 0-length resource, this is about 0-address. Look at
>>ide_hwif_confiure() in drivers/ide/setup-pci.c...
> The discussion I was having was about sl82cxx and handling unassigned
> resources. The zero address isn't relevant to that.
You were following up to the particular error message emitted by the IDE
core (which you've now deleted), so I corrected you on its reason, that's all.
>> You should know that the IRQ assumption is *not* true even for x86 since
>>IRQ0 is and has always been a perfectly valid IRQ (used by PIT).
> Please see previous million recyclings of that discussion and Linus
> answer.
When Linus remaps IRQ0 on x86, I'll follow that code as a testament. Until
this happens, I consider is just an opinion. Forcing every arch but x86 to
remap IRQ0 is an example of the double standards.
>>>Stick a real IDE resource at zero
>> > and drivers/ide can't cope.
>> Yeah, I've noticed. Unfortunately, a lot of PPC platforms (at least) are
>>doing exactly this...
> The checks need pushing upwards and removing from their current place -
> the pci layer should check the resource length, the isa pnp should I
> believe check for zero address etc.
So, it's OK to remove the base *address* check in ide_hwif_confiure()
altogether?
> libata makes a similar assumption in ata_resources_present() as someone
> (GregKH ???) needs to define what the proper way to encode "resource not
> allocated" into the PCI resources should be.
> If someone on the PCI list (cc'd) or Greg can give a definitive answer then we can go fix the
> offenders now.
Well, I thought that was IORESOURCE_UNSET...
> Alan
WBR, Sergei
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: What is the correct way to indicate an unassigned PCI resource ?
@ 2006-12-04 14:34 ` Sergei Shtylyov
0 siblings, 0 replies; 95+ messages in thread
From: Sergei Shtylyov @ 2006-12-04 14:34 UTC (permalink / raw)
To: Alan; +Cc: Olaf Hering, linuxppc-dev, greg, linux-ide, linux-pci
Hello.
Alan wrote:
>>>Both PCI core and IDE interpret a zero length resource as unassigned.
>> This is not about 0-length resource, this is about 0-address. Look at
>>ide_hwif_confiure() in drivers/ide/setup-pci.c...
> The discussion I was having was about sl82cxx and handling unassigned
> resources. The zero address isn't relevant to that.
You were following up to the particular error message emitted by the IDE
core (which you've now deleted), so I corrected you on its reason, that's all.
>> You should know that the IRQ assumption is *not* true even for x86 since
>>IRQ0 is and has always been a perfectly valid IRQ (used by PIT).
> Please see previous million recyclings of that discussion and Linus
> answer.
When Linus remaps IRQ0 on x86, I'll follow that code as a testament. Until
this happens, I consider is just an opinion. Forcing every arch but x86 to
remap IRQ0 is an example of the double standards.
>>>Stick a real IDE resource at zero
>> > and drivers/ide can't cope.
>> Yeah, I've noticed. Unfortunately, a lot of PPC platforms (at least) are
>>doing exactly this...
> The checks need pushing upwards and removing from their current place -
> the pci layer should check the resource length, the isa pnp should I
> believe check for zero address etc.
So, it's OK to remove the base *address* check in ide_hwif_confiure()
altogether?
> libata makes a similar assumption in ata_resources_present() as someone
> (GregKH ???) needs to define what the proper way to encode "resource not
> allocated" into the PCI resources should be.
> If someone on the PCI list (cc'd) or Greg can give a definitive answer then we can go fix the
> offenders now.
Well, I thought that was IORESOURCE_UNSET...
> Alan
WBR, Sergei
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: What is the correct way to indicate an unassigned PCI resource ?
2006-12-04 14:34 ` Sergei Shtylyov
(?)
@ 2006-12-04 14:44 ` Alan
2006-12-04 15:40 ` Sergei Shtylyov
-1 siblings, 1 reply; 95+ messages in thread
From: Alan @ 2006-12-04 14:44 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: Olaf Hering, linuxppc-dev, greg, linux-ide, linux-pci
> When Linus remaps IRQ0 on x86, I'll follow that code as a testament. Until
> this happens, I consider is just an opinion. Forcing every arch but x86 to
> remap IRQ0 is an example of the double standards.
Yawn.. x86 does not expose IRQ 0 outside of arch specific code.
> > The checks need pushing upwards and removing from their current place -
> > the pci layer should check the resource length, the isa pnp should I
> > believe check for zero address etc.
>
> So, it's OK to remove the base *address* check in ide_hwif_confiure()
> altogether?
IFF you move all the other checks, verify their correctness and then get
them tested for a while yes
> > libata makes a similar assumption in ata_resources_present() as someone
> > (GregKH ???) needs to define what the proper way to encode "resource not
> > allocated" into the PCI resources should be.
>
> > If someone on the PCI list (cc'd) or Greg can give a definitive answer then we can go fix the
> > offenders now.
>
> Well, I thought that was IORESOURCE_UNSET...
It seems to depend which line of code you ask - hence the question 8(
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: What is the correct way to indicate an unassigned PCI resource ?
2006-12-04 14:44 ` Alan
@ 2006-12-04 15:40 ` Sergei Shtylyov
0 siblings, 0 replies; 95+ messages in thread
From: Sergei Shtylyov @ 2006-12-04 15:40 UTC (permalink / raw)
To: Alan
Cc: Segher Boessenkool, Olaf Hering, linux-ide, linuxppc-dev, greg,
linux-pci
Hello.
Alan wrote:
>> When Linus remaps IRQ0 on x86, I'll follow that code as a testament. Until
>>this happens, I consider is just an opinion. Forcing every arch but x86 to
>>remap IRQ0 is an example of the double standards.
> Yawn.. x86 does not expose IRQ 0 outside of arch specific code.
Can you believe, some non-x86 platofrms also don't -- for example, IRQ0
may be internal to SOC, not shareable or routable outside of it, BUT the SOC
device is driven by the standard driver (I'm minding 8250.c here). Yet we're
told that we should remap it, period...
>>>The checks need pushing upwards and removing from their current place -
>>>the pci layer should check the resource length, the isa pnp should I
>>>believe check for zero address etc.
>> So, it's OK to remove the base *address* check in ide_hwif_confiure()
>>altogether?
> IFF you move all the other checks, verify their correctness and then get
> them tested for a while yes
All other checks aren't hindering (at least me ATM). What's probably
worth doing is to check the result of ide_pci_check_iomem() some lines above
the discussed check (it's ignored now).
WBR, Sergei
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: What is the correct way to indicate an unassigned PCI resource ?
@ 2006-12-04 15:40 ` Sergei Shtylyov
0 siblings, 0 replies; 95+ messages in thread
From: Sergei Shtylyov @ 2006-12-04 15:40 UTC (permalink / raw)
To: Alan; +Cc: Olaf Hering, linuxppc-dev, greg, linux-ide, linux-pci
Hello.
Alan wrote:
>> When Linus remaps IRQ0 on x86, I'll follow that code as a testament. Until
>>this happens, I consider is just an opinion. Forcing every arch but x86 to
>>remap IRQ0 is an example of the double standards.
> Yawn.. x86 does not expose IRQ 0 outside of arch specific code.
Can you believe, some non-x86 platofrms also don't -- for example, IRQ0
may be internal to SOC, not shareable or routable outside of it, BUT the SOC
device is driven by the standard driver (I'm minding 8250.c here). Yet we're
told that we should remap it, period...
>>>The checks need pushing upwards and removing from their current place -
>>>the pci layer should check the resource length, the isa pnp should I
>>>believe check for zero address etc.
>> So, it's OK to remove the base *address* check in ide_hwif_confiure()
>>altogether?
> IFF you move all the other checks, verify their correctness and then get
> them tested for a while yes
All other checks aren't hindering (at least me ATM). What's probably
worth doing is to check the result of ide_pci_check_iomem() some lines above
the discussed check (it's ignored now).
WBR, Sergei
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: What is the correct way to indicate an unassigned PCI resource ?
2006-12-04 15:40 ` Sergei Shtylyov
@ 2006-12-04 15:55 ` Sergei Shtylyov
-1 siblings, 0 replies; 95+ messages in thread
From: Sergei Shtylyov @ 2006-12-04 15:55 UTC (permalink / raw)
To: Alan; +Cc: Olaf Hering, linuxppc-dev, greg, linux-ide, linux-pci
Hello.
Sergei Shtylyov wrote:
>>> When Linus remaps IRQ0 on x86, I'll follow that code as a testament. Until
>>>this happens, I consider is just an opinion. Forcing every arch but x86 to
>>>remap IRQ0 is an example of the double standards.
>>Yawn.. x86 does not expose IRQ 0 outside of arch specific code.
> Can you believe, some non-x86 platofrms also don't -- for example, IRQ0
> may be internal to SOC, not shareable or routable outside of it, BUT the SOC
> device is driven by the standard driver (I'm minding 8250.c here). Yet we're
> told that we should remap it, period...
>>>>The checks need pushing upwards and removing from their current place -
>>>>the pci layer should check the resource length, the isa pnp should I
>>>>believe check for zero address etc.
Although, I'm getting the point -- PCI is likely to return 0 for
unassigned the interrupt line register (this isn't always true though). So,
some mixup is possible in that regard. Well, then we're unlucky, and indeed
remapping IRQ0 has sense...
WBR, Sergei
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: What is the correct way to indicate an unassigned PCI resource ?
@ 2006-12-04 15:55 ` Sergei Shtylyov
0 siblings, 0 replies; 95+ messages in thread
From: Sergei Shtylyov @ 2006-12-04 15:55 UTC (permalink / raw)
To: Alan; +Cc: linux-ide, linuxppc-dev, Olaf Hering, linux-pci, greg
Hello.
Sergei Shtylyov wrote:
>>> When Linus remaps IRQ0 on x86, I'll follow that code as a testament. Until
>>>this happens, I consider is just an opinion. Forcing every arch but x86 to
>>>remap IRQ0 is an example of the double standards.
>>Yawn.. x86 does not expose IRQ 0 outside of arch specific code.
> Can you believe, some non-x86 platofrms also don't -- for example, IRQ0
> may be internal to SOC, not shareable or routable outside of it, BUT the SOC
> device is driven by the standard driver (I'm minding 8250.c here). Yet we're
> told that we should remap it, period...
>>>>The checks need pushing upwards and removing from their current place -
>>>>the pci layer should check the resource length, the isa pnp should I
>>>>believe check for zero address etc.
Although, I'm getting the point -- PCI is likely to return 0 for
unassigned the interrupt line register (this isn't always true though). So,
some mixup is possible in that regard. Well, then we're unlucky, and indeed
remapping IRQ0 has sense...
WBR, Sergei
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: What is the correct way to indicate an unassigned PCI resource ?
2006-12-04 15:55 ` Sergei Shtylyov
@ 2006-12-04 20:53 ` Guennadi Liakhovetski
-1 siblings, 0 replies; 95+ messages in thread
From: Guennadi Liakhovetski @ 2006-12-04 20:53 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Alan, linux-ide, linuxppc-dev, Olaf Hering, linux-pci, greg
On Mon, 4 Dec 2006, Sergei Shtylyov wrote:
> >>> When Linus remaps IRQ0 on x86, I'll follow that code as a testament. Until
> >>>this happens, I consider is just an opinion. Forcing every arch but x86 to
> >>>remap IRQ0 is an example of the double standards.
Can I have a link to that specific answer from Linus, please? Somehow I
missed it.
> Although, I'm getting the point -- PCI is likely to return 0 for
> unassigned the interrupt line register (this isn't always true though). So,
> some mixup is possible in that regard. Well, then we're unlucky, and indeed
> remapping IRQ0 has sense...
Strange, if __PCI__ uses 0 for an unassigned IRQ line, I'd say it's
_internal_ PCI peculiarity, and should be handled by the PCI code, and not
be taken as an enforced definition by all architectures for the whole
system.
Why does one HAVE to remap IRQs if on a specific system it is easy and
natural to use 0 as a valid IRQ number?
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: What is the correct way to indicate an unassigned PCI resource ?
@ 2006-12-04 20:53 ` Guennadi Liakhovetski
0 siblings, 0 replies; 95+ messages in thread
From: Guennadi Liakhovetski @ 2006-12-04 20:53 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Olaf Hering, linuxppc-dev, greg, linux-ide, linux-pci, Alan
On Mon, 4 Dec 2006, Sergei Shtylyov wrote:
> >>> When Linus remaps IRQ0 on x86, I'll follow that code as a testament. Until
> >>>this happens, I consider is just an opinion. Forcing every arch but x86 to
> >>>remap IRQ0 is an example of the double standards.
Can I have a link to that specific answer from Linus, please? Somehow I
missed it.
> Although, I'm getting the point -- PCI is likely to return 0 for
> unassigned the interrupt line register (this isn't always true though). So,
> some mixup is possible in that regard. Well, then we're unlucky, and indeed
> remapping IRQ0 has sense...
Strange, if __PCI__ uses 0 for an unassigned IRQ line, I'd say it's
_internal_ PCI peculiarity, and should be handled by the PCI code, and not
be taken as an enforced definition by all architectures for the whole
system.
Why does one HAVE to remap IRQs if on a specific system it is easy and
natural to use 0 as a valid IRQ number?
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: What is the correct way to indicate an unassigned PCI resource ?
2006-12-04 14:22 ` What is the correct way to indicate an unassigned PCI resource ? Alan
@ 2006-12-05 4:41 ` Benjamin Herrenschmidt
2006-12-05 4:41 ` Benjamin Herrenschmidt
1 sibling, 0 replies; 95+ messages in thread
From: Benjamin Herrenschmidt @ 2006-12-05 4:41 UTC (permalink / raw)
To: Alan
Cc: Sergei Shtylyov, Olaf Hering, linuxppc-dev, greg, linux-ide, linux-pci
On Mon, 2006-12-04 at 14:22 +0000, Alan wrote:
> The discussion I was having was about sl82cxx and handling unassigned
> resources. The zero address isn't relevant to that.
Well, actually, it's unclear to me wether the resource is unassigned or
has been assigned to 0 :-) And in the later case, why claim'ing it
fails.
Olaf, can you give me a dump of /proc/ioports ? What is sitting at 0 on
that PCI bus ?
I have the "gut" feeling that the firmware didn't assign it, but it does
explicitely has an assigned-address property for it with value "0" and a
valid size & set of flags... so it looks like maybe it -really- did
assign it to 0. Either that or it's buggy.
In any case, if we have to do a fixup here, it would be a pSeries
specific fixup and thus would have to sit in a PCI quirk in the pSeries
platform code.
> > You should know that the IRQ assumption is *not* true even for x86 since
> > IRQ0 is and has always been a perfectly valid IRQ (used by PIT).
>
> Please see previous million recyclings of that discussion and Linus
> answer.
Besides, it does make thing easier in the kernel to consider IRQ 0 as
invalid. That's one of the reasons for which I generalized the IRQ
remapping layer in arch/powerpc. Among others, 0 is always invalid and
1...15 are always only ever assigned to a legacy 8259 if any, anything
else gets remapped.
> libata makes a similar assumption in ata_resources_present() as someone
> (GregKH ???) needs to define what the proper way to encode "resource not
> allocated" into the PCI resources should be. If someone on the PCI list
> (cc'd) or Greg can give a definitive answer then we can go fix the
> offenders now.
There is an UNSET flag isn't there ? Though nobody uses it ...
Ben.
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: What is the correct way to indicate an unassigned PCI resource ?
@ 2006-12-05 4:41 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 95+ messages in thread
From: Benjamin Herrenschmidt @ 2006-12-05 4:41 UTC (permalink / raw)
To: Alan; +Cc: Olaf Hering, linux-ide, greg, linuxppc-dev, linux-pci
On Mon, 2006-12-04 at 14:22 +0000, Alan wrote:
> The discussion I was having was about sl82cxx and handling unassigned
> resources. The zero address isn't relevant to that.
Well, actually, it's unclear to me wether the resource is unassigned or
has been assigned to 0 :-) And in the later case, why claim'ing it
fails.
Olaf, can you give me a dump of /proc/ioports ? What is sitting at 0 on
that PCI bus ?
I have the "gut" feeling that the firmware didn't assign it, but it does
explicitely has an assigned-address property for it with value "0" and a
valid size & set of flags... so it looks like maybe it -really- did
assign it to 0. Either that or it's buggy.
In any case, if we have to do a fixup here, it would be a pSeries
specific fixup and thus would have to sit in a PCI quirk in the pSeries
platform code.
> > You should know that the IRQ assumption is *not* true even for x86 since
> > IRQ0 is and has always been a perfectly valid IRQ (used by PIT).
>
> Please see previous million recyclings of that discussion and Linus
> answer.
Besides, it does make thing easier in the kernel to consider IRQ 0 as
invalid. That's one of the reasons for which I generalized the IRQ
remapping layer in arch/powerpc. Among others, 0 is always invalid and
1...15 are always only ever assigned to a legacy 8259 if any, anything
else gets remapped.
> libata makes a similar assumption in ata_resources_present() as someone
> (GregKH ???) needs to define what the proper way to encode "resource not
> allocated" into the PCI resources should be. If someone on the PCI list
> (cc'd) or Greg can give a definitive answer then we can go fix the
> offenders now.
There is an UNSET flag isn't there ? Though nobody uses it ...
Ben.
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: What is the correct way to indicate an unassigned PCI resource ?
2006-12-04 20:53 ` Guennadi Liakhovetski
@ 2006-12-05 4:43 ` Benjamin Herrenschmidt
-1 siblings, 0 replies; 95+ messages in thread
From: Benjamin Herrenschmidt @ 2006-12-05 4:43 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: Sergei Shtylyov, Olaf Hering, linuxppc-dev, greg, linux-ide,
linux-pci, Alan
On Mon, 2006-12-04 at 21:53 +0100, Guennadi Liakhovetski wrote:
> On Mon, 4 Dec 2006, Sergei Shtylyov wrote:
>
> > >>> When Linus remaps IRQ0 on x86, I'll follow that code as a testament. Until
> > >>>this happens, I consider is just an opinion. Forcing every arch but x86 to
> > >>>remap IRQ0 is an example of the double standards.
>
> Can I have a link to that specific answer from Linus, please? Somehow I
> missed it.
That debate is pointless. arch/powerpc now always remaps and 0 is always
illegal as a logical IRQ number, while it's perfectly legal as a HW
number on any PIC, so there is no more problem. Other archs might
probably want to do a similar remapping anyway as it makes loads of
things easier when you have multiple PICs and/or dynamically assigned
numbers.
Ben.
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: What is the correct way to indicate an unassigned PCI resource ?
@ 2006-12-05 4:43 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 95+ messages in thread
From: Benjamin Herrenschmidt @ 2006-12-05 4:43 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: Olaf Hering, linux-ide, greg, linuxppc-dev, linux-pci, Alan
On Mon, 2006-12-04 at 21:53 +0100, Guennadi Liakhovetski wrote:
> On Mon, 4 Dec 2006, Sergei Shtylyov wrote:
>
> > >>> When Linus remaps IRQ0 on x86, I'll follow that code as a testament. Until
> > >>>this happens, I consider is just an opinion. Forcing every arch but x86 to
> > >>>remap IRQ0 is an example of the double standards.
>
> Can I have a link to that specific answer from Linus, please? Somehow I
> missed it.
That debate is pointless. arch/powerpc now always remaps and 0 is always
illegal as a logical IRQ number, while it's perfectly legal as a HW
number on any PIC, so there is no more problem. Other archs might
probably want to do a similar remapping anyway as it makes loads of
things easier when you have multiple PICs and/or dynamically assigned
numbers.
Ben.
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: What is the correct way to indicate an unassigned PCI resource ?
2006-12-05 4:41 ` Benjamin Herrenschmidt
@ 2006-12-05 8:15 ` Olaf Hering
-1 siblings, 0 replies; 95+ messages in thread
From: Olaf Hering @ 2006-12-05 8:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Alan, Sergei Shtylyov, linuxppc-dev, greg, linux-ide, linux-pci
On Tue, Dec 05, Benjamin Herrenschmidt wrote:
> Olaf, can you give me a dump of /proc/ioports ? What is sitting at 0 on
> that PCI bus ?
with IDE=y
==> /proc/ioports <==
00000000-0000001f : dma1
00000020-00000021 : 8259 (master)
00000040-0000005f : timer
00000060-0000006f : i8042
00000080-0000008f : dma page reg
000000a0-000000a1 : 8259 (slave)
000000c0-000000df : dma2
000002f8-000002ff : serial
000003c0-000003df : matrox
000003f8-000003ff : serial
000004d0-000004d1 : 8259 edge control
00000898-0000089f : serial
0000f000-0000f007 : 0000:00:03.1
0000f000-0000f007 : ide0
0000f010-0000f013 : 0000:00:03.1
0000f012-0000f012 : ide0
0000f020-0000f027 : 0000:00:03.1
0000f030-0000f033 : 0000:00:03.1
0000f040-0000f04f : 0000:00:03.1
0000f040-0000f047 : ide0
0000f048-0000f04f : ide1
00010000-0001ffff : PCI Bus #01
00020000-0002ffff : PCI Bus #21
0002ec00-0002ec3f : 0000:21:01.0
0002ec00-0002ec3f : e100
00030000-0003ffff : PCI Bus #41
0003e800-0003e8ff : 0000:41:01.0
0003e800-0003e8ff : sym53c8xx
0003ec00-0003ecff : 0000:41:01.1
0003ec00-0003ecff : sym53c8xx
00040000-0004ffff : PCI Bus #61
00100000-001fffff : /pci@400000000112
00100000-0010ffff : PCI Bus #01
00110000-0011ffff : PCI Bus #21
0011ec00-0011ec3f : 0001:21:01.0
0011ec00-0011ec3f : e100
00120000-0012ffff : PCI Bus #61
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: What is the correct way to indicate an unassigned PCI resource ?
@ 2006-12-05 8:15 ` Olaf Hering
0 siblings, 0 replies; 95+ messages in thread
From: Olaf Hering @ 2006-12-05 8:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linux-ide, greg, linuxppc-dev, linux-pci, Alan
On Tue, Dec 05, Benjamin Herrenschmidt wrote:
> Olaf, can you give me a dump of /proc/ioports ? What is sitting at 0 on
> that PCI bus ?
with IDE=y
==> /proc/ioports <==
00000000-0000001f : dma1
00000020-00000021 : 8259 (master)
00000040-0000005f : timer
00000060-0000006f : i8042
00000080-0000008f : dma page reg
000000a0-000000a1 : 8259 (slave)
000000c0-000000df : dma2
000002f8-000002ff : serial
000003c0-000003df : matrox
000003f8-000003ff : serial
000004d0-000004d1 : 8259 edge control
00000898-0000089f : serial
0000f000-0000f007 : 0000:00:03.1
0000f000-0000f007 : ide0
0000f010-0000f013 : 0000:00:03.1
0000f012-0000f012 : ide0
0000f020-0000f027 : 0000:00:03.1
0000f030-0000f033 : 0000:00:03.1
0000f040-0000f04f : 0000:00:03.1
0000f040-0000f047 : ide0
0000f048-0000f04f : ide1
00010000-0001ffff : PCI Bus #01
00020000-0002ffff : PCI Bus #21
0002ec00-0002ec3f : 0000:21:01.0
0002ec00-0002ec3f : e100
00030000-0003ffff : PCI Bus #41
0003e800-0003e8ff : 0000:41:01.0
0003e800-0003e8ff : sym53c8xx
0003ec00-0003ecff : 0000:41:01.1
0003ec00-0003ecff : sym53c8xx
00040000-0004ffff : PCI Bus #61
00100000-001fffff : /pci@400000000112
00100000-0010ffff : PCI Bus #01
00110000-0011ffff : PCI Bus #21
0011ec00-0011ec3f : 0001:21:01.0
0011ec00-0011ec3f : e100
00120000-0012ffff : PCI Bus #61
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: What is the correct way to indicate an unassigned PCI resource ?
2006-12-05 4:41 ` Benjamin Herrenschmidt
@ 2006-12-05 10:51 ` Gabriel Paubert
-1 siblings, 0 replies; 95+ messages in thread
From: Gabriel Paubert @ 2006-12-05 10:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Alan, Olaf Hering, linux-ide, greg, linuxppc-dev, linux-pci
On Tue, Dec 05, 2006 at 03:41:19PM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2006-12-04 at 14:22 +0000, Alan wrote:
>
> > The discussion I was having was about sl82cxx and handling unassigned
> > resources. The zero address isn't relevant to that.
>
> Well, actually, it's unclear to me wether the resource is unassigned or
> has been assigned to 0 :-) And in the later case, why claim'ing it
> fails.
Well, I don't have the PCI specification, but I have a device with the
following gem in its errata (name edited and changed to <Device>):
""The <Device> contains two PCI base registers to allow for both greater
flexibility in tightly constrained I/O space as well as the "on the fly"
option to access the <Device> registers from either I/O or memory space.
Both PCI base registers contained in the <Device> will accept the value
of "zero" as a valid and decodable address. This differs from the PCI 2.1
specification, where a zero value being written to the PCI base register
should disable the register space. <Device> will continue to decode for
register accesses using the value "zero" written to the PCI_BS register
as the base address for decoding.""
which makes me suspect that a base address of zero really should mean
unassigned and is a way to disable base registers on a region by region
basis.
Now the fun with this device is that the I/O region occupies 4kB, so
it leads to serious conflicts since there is also an ISA bridge in
the system (no 8259 anymore, serial console dead, etc...). The best
way to make this bug harmless is to write all ones to said base
register (it has 32 bit). This moves it to an address which cannot
be generated by the host bridge (unless you program it in a really
weird way).
Whatever a specification says, you'll always find some device that
has a bug in this area.
Regards,
Gabriel
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: What is the correct way to indicate an unassigned PCI resource ?
@ 2006-12-05 10:51 ` Gabriel Paubert
0 siblings, 0 replies; 95+ messages in thread
From: Gabriel Paubert @ 2006-12-05 10:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Olaf Hering, linux-ide, greg, linuxppc-dev, linux-pci, Alan
On Tue, Dec 05, 2006 at 03:41:19PM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2006-12-04 at 14:22 +0000, Alan wrote:
>
> > The discussion I was having was about sl82cxx and handling unassigned
> > resources. The zero address isn't relevant to that.
>
> Well, actually, it's unclear to me wether the resource is unassigned or
> has been assigned to 0 :-) And in the later case, why claim'ing it
> fails.
Well, I don't have the PCI specification, but I have a device with the
following gem in its errata (name edited and changed to <Device>):
""The <Device> contains two PCI base registers to allow for both greater
flexibility in tightly constrained I/O space as well as the "on the fly"
option to access the <Device> registers from either I/O or memory space.
Both PCI base registers contained in the <Device> will accept the value
of "zero" as a valid and decodable address. This differs from the PCI 2.1
specification, where a zero value being written to the PCI base register
should disable the register space. <Device> will continue to decode for
register accesses using the value "zero" written to the PCI_BS register
as the base address for decoding.""
which makes me suspect that a base address of zero really should mean
unassigned and is a way to disable base registers on a region by region
basis.
Now the fun with this device is that the I/O region occupies 4kB, so
it leads to serious conflicts since there is also an ISA bridge in
the system (no 8259 anymore, serial console dead, etc...). The best
way to make this bug harmless is to write all ones to said base
register (it has 32 bit). This moves it to an address which cannot
be generated by the host bridge (unless you program it in a really
weird way).
Whatever a specification says, you'll always find some device that
has a bug in this area.
Regards,
Gabriel
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: What is the correct way to indicate an unassigned PCI resource ?
2006-12-05 10:51 ` Gabriel Paubert
@ 2006-12-05 12:38 ` Sergei Shtylyov
-1 siblings, 0 replies; 95+ messages in thread
From: Sergei Shtylyov @ 2006-12-05 12:38 UTC (permalink / raw)
To: Gabriel Paubert
Cc: Benjamin Herrenschmidt, Olaf Hering, linux-ide, greg,
linuxppc-dev, linux-pci, Alan
Hello.
Gabriel Paubert wrote:
>>On Mon, 2006-12-04 at 14:22 +0000, Alan wrote:
>>>The discussion I was having was about sl82cxx and handling unassigned
>>>resources. The zero address isn't relevant to that.
>>Well, actually, it's unclear to me wether the resource is unassigned or
>>has been assigned to 0 :-) And in the later case, why claim'ing it
>>fails.
> Well, I don't have the PCI specification, but I have a device with the
Try googling for pdf21.pdf, pdf22.pdf if you need it. :-)
> following gem in its errata (name edited and changed to <Device>):
> ""The <Device> contains two PCI base registers to allow for both greater
> flexibility in tightly constrained I/O space as well as the "on the fly"
> option to access the <Device> registers from either I/O or memory space.
> Both PCI base registers contained in the <Device> will accept the value
> of "zero" as a valid and decodable address. This differs from the PCI 2.1
> specification, where a zero value being written to the PCI base register
> should disable the register space.
I haven't found such words in PCI 2.1 -- it only said that 0 is not a
valid address (those words are gone from 2.2).
> <Device> will continue to decode for
> register accesses using the value "zero" written to the PCI_BS register
> as the base address for decoding.""
I'd say it's absolutely valid bahavior.
> which makes me suspect that a base address of zero really should mean
> unassigned and is a way to disable base registers on a region by region
> basis.
AFAIR, there's never been a provision to enable/disable BARs on an
individual basis in PCI (except the expansion ROM BAR). The decoders are
only controlled via 2 command register bits for I/O and memory space.
> Now the fun with this device is that the I/O region occupies 4kB, so
That's a crappy device indeed, I/O alloction limit is 256 bytes (that's
due to PC-specific limitation actually). Such regions may (and should) be left
unassigned by f/w (and I/O decoder disabled).
> it leads to serious conflicts since there is also an ISA bridge in
> the system (no 8259 anymore, serial console dead, etc...). The best
> way to make this bug harmless is to write all ones to said base
> register (it has 32 bit). This moves it to an address which cannot
> be generated by the host bridge (unless you program it in a really
> weird way).
You may also completely disable the I/O decoder for this device.
> Whatever a specification says, you'll always find some device that
> has a bug in this area.
Yeah. I've already encountered such one...
WBR, Sergei
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: What is the correct way to indicate an unassigned PCI resource ?
@ 2006-12-05 12:38 ` Sergei Shtylyov
0 siblings, 0 replies; 95+ messages in thread
From: Sergei Shtylyov @ 2006-12-05 12:38 UTC (permalink / raw)
To: Gabriel Paubert
Cc: Olaf Hering, linux-ide, linuxppc-dev, greg, linux-pci, Alan
Hello.
Gabriel Paubert wrote:
>>On Mon, 2006-12-04 at 14:22 +0000, Alan wrote:
>>>The discussion I was having was about sl82cxx and handling unassigned
>>>resources. The zero address isn't relevant to that.
>>Well, actually, it's unclear to me wether the resource is unassigned or
>>has been assigned to 0 :-) And in the later case, why claim'ing it
>>fails.
> Well, I don't have the PCI specification, but I have a device with the
Try googling for pdf21.pdf, pdf22.pdf if you need it. :-)
> following gem in its errata (name edited and changed to <Device>):
> ""The <Device> contains two PCI base registers to allow for both greater
> flexibility in tightly constrained I/O space as well as the "on the fly"
> option to access the <Device> registers from either I/O or memory space.
> Both PCI base registers contained in the <Device> will accept the value
> of "zero" as a valid and decodable address. This differs from the PCI 2.1
> specification, where a zero value being written to the PCI base register
> should disable the register space.
I haven't found such words in PCI 2.1 -- it only said that 0 is not a
valid address (those words are gone from 2.2).
> <Device> will continue to decode for
> register accesses using the value "zero" written to the PCI_BS register
> as the base address for decoding.""
I'd say it's absolutely valid bahavior.
> which makes me suspect that a base address of zero really should mean
> unassigned and is a way to disable base registers on a region by region
> basis.
AFAIR, there's never been a provision to enable/disable BARs on an
individual basis in PCI (except the expansion ROM BAR). The decoders are
only controlled via 2 command register bits for I/O and memory space.
> Now the fun with this device is that the I/O region occupies 4kB, so
That's a crappy device indeed, I/O alloction limit is 256 bytes (that's
due to PC-specific limitation actually). Such regions may (and should) be left
unassigned by f/w (and I/O decoder disabled).
> it leads to serious conflicts since there is also an ISA bridge in
> the system (no 8259 anymore, serial console dead, etc...). The best
> way to make this bug harmless is to write all ones to said base
> register (it has 32 bit). This moves it to an address which cannot
> be generated by the host bridge (unless you program it in a really
> weird way).
You may also completely disable the I/O decoder for this device.
> Whatever a specification says, you'll always find some device that
> has a bug in this area.
Yeah. I've already encountered such one...
WBR, Sergei
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: What is the correct way to indicate an unassigned PCI resource ?
2006-12-05 12:38 ` Sergei Shtylyov
@ 2006-12-05 17:37 ` Grant Grundler
-1 siblings, 0 replies; 95+ messages in thread
From: Grant Grundler @ 2006-12-05 17:37 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Gabriel Paubert, Benjamin Herrenschmidt, Olaf Hering, linux-ide,
greg, linuxppc-dev, linux-pci, Alan
On Tue, Dec 05, 2006 at 03:38:57PM +0300, Sergei Shtylyov wrote:
> >Well, I don't have the PCI specification, but I have a device with the
>
> Try googling for pdf21.pdf, pdf22.pdf if you need it. :-)
I think you meant pci21.pdf/pci22.pdf/pci23.pdf.
And if you find them, trust me when I say whoever is hosting those files
can expect a cease-and-desist letter in the mail shortly there after.
Better to just ask someone with proper access to lookup the parts
you need to know (i.e. ask here). Member companies are listed at:
http://www.pcisig.com/membership/about_us/membership_roster/
if you want to approach someone offlist.
> >following gem in its errata (name edited and changed to <Device>):
>
> >""The <Device> contains two PCI base registers to allow for both greater
> >flexibility in tightly constrained I/O space as well as the "on the fly"
> >option to access the <Device> registers from either I/O or memory space.
> >Both PCI base registers contained in the <Device> will accept the value
> >of "zero" as a valid and decodable address. This differs from the PCI 2.1
> >specification, where a zero value being written to the PCI base register
> >should disable the register space.
>
> I haven't found such words in PCI 2.1 -- it only said that 0 is not a
> valid address (those words are gone from 2.2).
AFAIK, zero is a valid address for IO Port space on several architectures.
But PCI generic code should never use it. See usage of PCIBIOS_MIN_IO
and PCIBIOS_MIN_MEM in the various asm-*/pci.h files.
> ><Device> will continue to decode for
> >register accesses using the value "zero" written to the PCI_BS register
> >as the base address for decoding.""
>
> I'd say it's absolutely valid bahavior.
>
> >which makes me suspect that a base address of zero really should mean
> >unassigned and is a way to disable base registers on a region by region
> >basis.
>
> AFAIR, there's never been a provision to enable/disable BARs on an
> individual basis in PCI (except the expansion ROM BAR). The decoders are
> only controlled via 2 command register bits for I/O and memory space.
One can "disable" a BAR by pointing it at an address that is NOT routed
by the upstream bridge. Ie CPU physical addresses that can never reach
that secondary bus. But I'm not aware of any code to do that currently
and it certainly won't work with all "PCI-like" (think integrated south
bridges) devices. But it might be sufficient for some special need.
hth,
grant
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: What is the correct way to indicate an unassigned PCI resource ?
@ 2006-12-05 17:37 ` Grant Grundler
0 siblings, 0 replies; 95+ messages in thread
From: Grant Grundler @ 2006-12-05 17:37 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Olaf Hering, linux-ide, linuxppc-dev, greg, linux-pci, Alan
On Tue, Dec 05, 2006 at 03:38:57PM +0300, Sergei Shtylyov wrote:
> >Well, I don't have the PCI specification, but I have a device with the
>
> Try googling for pdf21.pdf, pdf22.pdf if you need it. :-)
I think you meant pci21.pdf/pci22.pdf/pci23.pdf.
And if you find them, trust me when I say whoever is hosting those files
can expect a cease-and-desist letter in the mail shortly there after.
Better to just ask someone with proper access to lookup the parts
you need to know (i.e. ask here). Member companies are listed at:
http://www.pcisig.com/membership/about_us/membership_roster/
if you want to approach someone offlist.
> >following gem in its errata (name edited and changed to <Device>):
>
> >""The <Device> contains two PCI base registers to allow for both greater
> >flexibility in tightly constrained I/O space as well as the "on the fly"
> >option to access the <Device> registers from either I/O or memory space.
> >Both PCI base registers contained in the <Device> will accept the value
> >of "zero" as a valid and decodable address. This differs from the PCI 2.1
> >specification, where a zero value being written to the PCI base register
> >should disable the register space.
>
> I haven't found such words in PCI 2.1 -- it only said that 0 is not a
> valid address (those words are gone from 2.2).
AFAIK, zero is a valid address for IO Port space on several architectures.
But PCI generic code should never use it. See usage of PCIBIOS_MIN_IO
and PCIBIOS_MIN_MEM in the various asm-*/pci.h files.
> ><Device> will continue to decode for
> >register accesses using the value "zero" written to the PCI_BS register
> >as the base address for decoding.""
>
> I'd say it's absolutely valid bahavior.
>
> >which makes me suspect that a base address of zero really should mean
> >unassigned and is a way to disable base registers on a region by region
> >basis.
>
> AFAIR, there's never been a provision to enable/disable BARs on an
> individual basis in PCI (except the expansion ROM BAR). The decoders are
> only controlled via 2 command register bits for I/O and memory space.
One can "disable" a BAR by pointing it at an address that is NOT routed
by the upstream bridge. Ie CPU physical addresses that can never reach
that secondary bus. But I'm not aware of any code to do that currently
and it certainly won't work with all "PCI-like" (think integrated south
bridges) devices. But it might be sufficient for some special need.
hth,
grant
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: What is the correct way to indicate an unassigned PCI resource ?
2006-12-05 17:37 ` Grant Grundler
@ 2006-12-05 19:22 ` Sergei Shtylyov
-1 siblings, 0 replies; 95+ messages in thread
From: Sergei Shtylyov @ 2006-12-05 19:22 UTC (permalink / raw)
To: Grant Grundler
Cc: Gabriel Paubert, Benjamin Herrenschmidt, Olaf Hering, linux-ide,
greg, linuxppc-dev, linux-pci, Alan
Hello.
Grant Grundler wrote:
>>>Well, I don't have the PCI specification, but I have a device with the
>> Try googling for pdf21.pdf, pdf22.pdf if you need it. :-)
> I think you meant pci21.pdf/pci22.pdf/pci23.pdf.
> And if you find them, trust me when I say whoever is hosting those files
> can expect a cease-and-desist letter in the mail shortly there after.
> Better to just ask someone with proper access to lookup the parts
> you need to know (i.e. ask here). Member companies are listed at:
> http://www.pcisig.com/membership/about_us/membership_roster/
> if you want to approach someone offlist.
That's not fun. :-)
>>>following gem in its errata (name edited and changed to <Device>):
>>>""The <Device> contains two PCI base registers to allow for both greater
>>>flexibility in tightly constrained I/O space as well as the "on the fly"
>>>option to access the <Device> registers from either I/O or memory space.
>>>Both PCI base registers contained in the <Device> will accept the value
>>>of "zero" as a valid and decodable address. This differs from the PCI 2.1
>>>specification, where a zero value being written to the PCI base register
>>>should disable the register space.
>> I haven't found such words in PCI 2.1 -- it only said that 0 is not a
>>valid address (those words are gone from 2.2).
> AFAIK, zero is a valid address for IO Port space on several architectures.
> But PCI generic code should never use it. See usage of PCIBIOS_MIN_IO
> and PCIBIOS_MIN_MEM in the various asm-*/pci.h files.
That'd be all good if bootloaders also folllowed this rule... Not all of
them do, hence the thread. :-/
>>>which makes me suspect that a base address of zero really should mean
>>>unassigned and is a way to disable base registers on a region by region
>>>basis.
>> AFAIR, there's never been a provision to enable/disable BARs on an
>>individual basis in PCI (except the expansion ROM BAR). The decoders are
>>only controlled via 2 command register bits for I/O and memory space.
> One can "disable" a BAR by pointing it at an address that is NOT routed
> by the upstream bridge. Ie CPU physical addresses that can never reach
> that secondary bus. But I'm not aware of any code to do that currently
Yeah, that's the trick that Gabriel has already described...
> and it certainly won't work with all "PCI-like" (think integrated south
> bridges) devices.
Well, those are using subtractive decoders, so will only get the R/W
cycles that nobody else cared about. If using I/O ports higher than 0xffff the
trick will still work on x86 even in presence of ISA bridges...
> hth,
> grant
WBR, Sergei
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: What is the correct way to indicate an unassigned PCI resource ?
@ 2006-12-05 19:22 ` Sergei Shtylyov
0 siblings, 0 replies; 95+ messages in thread
From: Sergei Shtylyov @ 2006-12-05 19:22 UTC (permalink / raw)
To: Grant Grundler
Cc: Olaf Hering, linux-ide, linuxppc-dev, greg, linux-pci, Alan
Hello.
Grant Grundler wrote:
>>>Well, I don't have the PCI specification, but I have a device with the
>> Try googling for pdf21.pdf, pdf22.pdf if you need it. :-)
> I think you meant pci21.pdf/pci22.pdf/pci23.pdf.
> And if you find them, trust me when I say whoever is hosting those files
> can expect a cease-and-desist letter in the mail shortly there after.
> Better to just ask someone with proper access to lookup the parts
> you need to know (i.e. ask here). Member companies are listed at:
> http://www.pcisig.com/membership/about_us/membership_roster/
> if you want to approach someone offlist.
That's not fun. :-)
>>>following gem in its errata (name edited and changed to <Device>):
>>>""The <Device> contains two PCI base registers to allow for both greater
>>>flexibility in tightly constrained I/O space as well as the "on the fly"
>>>option to access the <Device> registers from either I/O or memory space.
>>>Both PCI base registers contained in the <Device> will accept the value
>>>of "zero" as a valid and decodable address. This differs from the PCI 2.1
>>>specification, where a zero value being written to the PCI base register
>>>should disable the register space.
>> I haven't found such words in PCI 2.1 -- it only said that 0 is not a
>>valid address (those words are gone from 2.2).
> AFAIK, zero is a valid address for IO Port space on several architectures.
> But PCI generic code should never use it. See usage of PCIBIOS_MIN_IO
> and PCIBIOS_MIN_MEM in the various asm-*/pci.h files.
That'd be all good if bootloaders also folllowed this rule... Not all of
them do, hence the thread. :-/
>>>which makes me suspect that a base address of zero really should mean
>>>unassigned and is a way to disable base registers on a region by region
>>>basis.
>> AFAIR, there's never been a provision to enable/disable BARs on an
>>individual basis in PCI (except the expansion ROM BAR). The decoders are
>>only controlled via 2 command register bits for I/O and memory space.
> One can "disable" a BAR by pointing it at an address that is NOT routed
> by the upstream bridge. Ie CPU physical addresses that can never reach
> that secondary bus. But I'm not aware of any code to do that currently
Yeah, that's the trick that Gabriel has already described...
> and it certainly won't work with all "PCI-like" (think integrated south
> bridges) devices.
Well, those are using subtractive decoders, so will only get the R/W
cycles that nobody else cared about. If using I/O ports higher than 0xffff the
trick will still work on x86 even in presence of ISA bridges...
> hth,
> grant
WBR, Sergei
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: What is the correct way to indicate an unassigned PCI resource ?
2006-12-05 8:15 ` Olaf Hering
@ 2006-12-05 20:19 ` Benjamin Herrenschmidt
-1 siblings, 0 replies; 95+ messages in thread
From: Benjamin Herrenschmidt @ 2006-12-05 20:19 UTC (permalink / raw)
To: Olaf Hering
Cc: Alan, Sergei Shtylyov, linuxppc-dev, greg, linux-ide, linux-pci
On Tue, 2006-12-05 at 09:15 +0100, Olaf Hering wrote:
> On Tue, Dec 05, Benjamin Herrenschmidt wrote:
>
> > Olaf, can you give me a dump of /proc/ioports ? What is sitting at 0 on
> > that PCI bus ?
>
> with IDE=y
>
> ==> /proc/ioports <==
> 00000000-0000001f : dma1
So it's indeed colliding with the cruft above.
I reckon it's a bug in the firmware of this machine.
Add to pseries/pci.c a quirk for that chipset (don't forget to test for
machine_is(pseries) in the quirk as they get called for all platforms in
a combo kernel. The quirk shall check if resource 6 has a 0 base and
clear the size as Alan suggested (possibly setting the UNSET flag as
well).
Ben.
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: What is the correct way to indicate an unassigned PCI resource ?
@ 2006-12-05 20:19 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 95+ messages in thread
From: Benjamin Herrenschmidt @ 2006-12-05 20:19 UTC (permalink / raw)
To: Olaf Hering; +Cc: linux-ide, greg, linuxppc-dev, linux-pci, Alan
On Tue, 2006-12-05 at 09:15 +0100, Olaf Hering wrote:
> On Tue, Dec 05, Benjamin Herrenschmidt wrote:
>
> > Olaf, can you give me a dump of /proc/ioports ? What is sitting at 0 on
> > that PCI bus ?
>
> with IDE=y
>
> ==> /proc/ioports <==
> 00000000-0000001f : dma1
So it's indeed colliding with the cruft above.
I reckon it's a bug in the firmware of this machine.
Add to pseries/pci.c a quirk for that chipset (don't forget to test for
machine_is(pseries) in the quirk as they get called for all platforms in
a combo kernel. The quirk shall check if resource 6 has a 0 base and
clear the size as Alan suggested (possibly setting the UNSET flag as
well).
Ben.
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: What is the correct way to indicate an unassigned PCI resource ?
2006-12-05 20:19 ` Benjamin Herrenschmidt
@ 2006-12-05 21:26 ` Sergei Shtylyov
-1 siblings, 0 replies; 95+ messages in thread
From: Sergei Shtylyov @ 2006-12-05 21:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Olaf Hering, Alan, linuxppc-dev, greg, linux-ide, linux-pci
Hello.
Benjamin Herrenschmidt wrote:
>>On Tue, Dec 05, Benjamin Herrenschmidt wrote:
>>>Olaf, can you give me a dump of /proc/ioports ? What is sitting at 0 on
>>>that PCI bus ?
>>with IDE=y
>>==> /proc/ioports <==
>>00000000-0000001f : dma1
> So it's indeed colliding with the cruft above.
> I reckon it's a bug in the firmware of this machine.
> Add to pseries/pci.c a quirk for that chipset (don't forget to test for
> machine_is(pseries) in the quirk as they get called for all platforms in
> a combo kernel. The quirk shall check if resource 6 has a 0 base and
> clear the size as Alan suggested (possibly setting the UNSET flag as
> well).
Erm, I suspect it's either one or another -- you probably need to keep the
size intact for resource marked IORESOURCE_UNSET. At least that's what the
other code does...
> Ben.
WBR, Sergei
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: What is the correct way to indicate an unassigned PCI resource ?
@ 2006-12-05 21:26 ` Sergei Shtylyov
0 siblings, 0 replies; 95+ messages in thread
From: Sergei Shtylyov @ 2006-12-05 21:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Olaf Hering, linuxppc-dev, greg, linux-ide, linux-pci, Alan
Hello.
Benjamin Herrenschmidt wrote:
>>On Tue, Dec 05, Benjamin Herrenschmidt wrote:
>>>Olaf, can you give me a dump of /proc/ioports ? What is sitting at 0 on
>>>that PCI bus ?
>>with IDE=y
>>==> /proc/ioports <==
>>00000000-0000001f : dma1
> So it's indeed colliding with the cruft above.
> I reckon it's a bug in the firmware of this machine.
> Add to pseries/pci.c a quirk for that chipset (don't forget to test for
> machine_is(pseries) in the quirk as they get called for all platforms in
> a combo kernel. The quirk shall check if resource 6 has a 0 base and
> clear the size as Alan suggested (possibly setting the UNSET flag as
> well).
Erm, I suspect it's either one or another -- you probably need to keep the
size intact for resource marked IORESOURCE_UNSET. At least that's what the
other code does...
> Ben.
WBR, Sergei
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [U-Boot-Users] U-Boot allocating PCI I/O space from 0 (Was: pata_sl82c105 can not reserve IO region)
2006-12-02 16:33 ` [U-Boot-Users] " Sergei Shtylyov
@ 2006-12-26 20:53 ` Sergei Shtylyov
-1 siblings, 0 replies; 95+ messages in thread
From: Sergei Shtylyov @ 2006-12-26 20:53 UTC (permalink / raw)
To: u-boot-users; +Cc: linuxppc-embedded
Hello, I wrote:
>> Well, I'm having a very related issue with the U-Boot on MPC85xx: recently
>>I've noticed that it started allocating PCI I/O space from 0 (while the older
>>versions started from 0x1000). The IDE core can't tolerate this, giving me
>>such messages on bootup:
>>PDC20269: inconsistent baseregs (BIOS) for port 0, skipping
This is due to U-Boot assigning the PCI resources fram address 0 (which is
BTW illegal according to PCI 2.1). I have a patch for drivers/pci_auto.c
which I'm going to post tomorrow...
>>when I have Promise Ultra133TX2 card inserted into PCI alone. I've looked thru
>>the U-Boot sources and commit history but failed to locate the change that led
>>to this...
> It's actually much worse than just that. When I also plug in some other
> PCI card so Ultra133TX2 doesn't get the zero addresses anymore, I'm getting this:
> eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin
> <saw@saw.sw.com.sg> and others
> eth3: Invalid EEPROM checksum 0xfffe, check settings before activating this
> device!
> eth3: OEM i82557/i82558 10/100 Ethernet, 00:00:00:00:FF:FF, IRQ 52.
> [...]
> PDC20269: 100% native mode on irq 51
> ide2: BM-DMA at 0x0060-0x0067, BIOS settings: hde:pio, hdf:pio
> PDC20269: simplex device: DMA disabled
> ide3: PDC20269 Bus-Master DMA disabled (BIOS)
> I've just verified that both these cards are working OK in x86 box
> As for the simplex message, I've encountered this some months ago and it was
> caused by invalid programming of the MPC85xx bridge PCI/X outbound translation
> address register for the I/O space
No, the programming was valid. I've finally found the ultimate reason of
breakage -- it lies in board/*/init.S files. The patch tomorrow...
> or at least by the non-zero value of the
> bus I/O address in the "ranges" property of the bridge device node in the
> device tree...
It was the real reason -- the arch/powerpc/ kernel just ignores ranges
with non-zero I/O port address.
> I'm somewhat confused now since I know that the relevant U-Boot
> code has been fixed but it looks like that made it only worse -- I was using
> the custom patched version of U-Boot before which missed that fix:
> http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commitdiff;h=97074ed9655309b64231bc2cee69fe85399f8055
It was actually the following patch that broke PCI:
http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commit;h=52c7a68b8d587ebcf5a6b051b58b3d3ffa377ddc
There were other places relying on CFG_PCI1_IO_BASE and those weren't
changed... sigh. :-/
WBR, Sergei
^ permalink raw reply [flat|nested] 95+ messages in thread
* [U-Boot-Users] U-Boot allocating PCI I/O space from 0 (Was: pata_sl82c105 can not reserve IO region)
@ 2006-12-26 20:53 ` Sergei Shtylyov
0 siblings, 0 replies; 95+ messages in thread
From: Sergei Shtylyov @ 2006-12-26 20:53 UTC (permalink / raw)
To: u-boot
Hello, I wrote:
>> Well, I'm having a very related issue with the U-Boot on MPC85xx: recently
>>I've noticed that it started allocating PCI I/O space from 0 (while the older
>>versions started from 0x1000). The IDE core can't tolerate this, giving me
>>such messages on bootup:
>>PDC20269: inconsistent baseregs (BIOS) for port 0, skipping
This is due to U-Boot assigning the PCI resources fram address 0 (which is
BTW illegal according to PCI 2.1). I have a patch for drivers/pci_auto.c
which I'm going to post tomorrow...
>>when I have Promise Ultra133TX2 card inserted into PCI alone. I've looked thru
>>the U-Boot sources and commit history but failed to locate the change that led
>>to this...
> It's actually much worse than just that. When I also plug in some other
> PCI card so Ultra133TX2 doesn't get the zero addresses anymore, I'm getting this:
> eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin
> <saw@saw.sw.com.sg> and others
> eth3: Invalid EEPROM checksum 0xfffe, check settings before activating this
> device!
> eth3: OEM i82557/i82558 10/100 Ethernet, 00:00:00:00:FF:FF, IRQ 52.
> [...]
> PDC20269: 100% native mode on irq 51
> ide2: BM-DMA at 0x0060-0x0067, BIOS settings: hde:pio, hdf:pio
> PDC20269: simplex device: DMA disabled
> ide3: PDC20269 Bus-Master DMA disabled (BIOS)
> I've just verified that both these cards are working OK in x86 box
> As for the simplex message, I've encountered this some months ago and it was
> caused by invalid programming of the MPC85xx bridge PCI/X outbound translation
> address register for the I/O space
No, the programming was valid. I've finally found the ultimate reason of
breakage -- it lies in board/*/init.S files. The patch tomorrow...
> or at least by the non-zero value of the
> bus I/O address in the "ranges" property of the bridge device node in the
> device tree...
It was the real reason -- the arch/powerpc/ kernel just ignores ranges
with non-zero I/O port address.
> I'm somewhat confused now since I know that the relevant U-Boot
> code has been fixed but it looks like that made it only worse -- I was using
> the custom patched version of U-Boot before which missed that fix:
> http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commitdiff;h=97074ed9655309b64231bc2cee69fe85399f8055
It was actually the following patch that broke PCI:
http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commit;h=52c7a68b8d587ebcf5a6b051b58b3d3ffa377ddc
There were other places relying on CFG_PCI1_IO_BASE and those weren't
changed... sigh. :-/
WBR, Sergei
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH] add delay around sl82c105_reset_engine calls
2006-12-04 13:02 ` Alan
2006-12-04 13:12 ` Olaf Hering
@ 2007-01-04 6:42 ` Olaf Hering
2007-01-04 10:53 ` Alan
1 sibling, 1 reply; 95+ messages in thread
From: Olaf Hering @ 2007-01-04 6:42 UTC (permalink / raw)
To: Alan; +Cc: linux-ide, linuxppc-dev
On Mon, Dec 04, Alan wrote:
> On Mon, 4 Dec 2006 13:40:26 +0100 (MET)
> Olaf Hering <olaf@aepfle.de> wrote:
>
> >
> >
> > the hald media changed polling does really confuse things.
> > noone knows why the delays are needed, but they give us access to
> > the CD.
>
> Can you tell me what happens if you completely pull the reset out of the
> dma_end function. Do you still need delays then.
An udelay(50) will give reliable access to the drive, but there is still
one (or more) EH reset. The drive works without EH resets with udelay(100).
Signed-off-by: Olaf Hering <olaf@aepfle.de>
---
drivers/ata/pata_sl82c105.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/ata/pata_sl82c105.c
+++ b/drivers/ata/pata_sl82c105.c
@@ -187,7 +187,9 @@ static void sl82c105_bmdma_start(struct
{
struct ata_port *ap = qc->ap;
+ udelay(100);
sl82c105_reset_engine(ap);
+ udelay(100);
/* Set the clocks for DMA */
sl82c105_configure_dmamode(ap, qc->dev);
@@ -216,6 +218,7 @@ static void sl82c105_bmdma_stop(struct a
ata_bmdma_stop(qc);
sl82c105_reset_engine(ap);
+ udelay(100);
/* This will redo the initial setup of the DMA device to matching
PIO timings */
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH] add delay around sl82c105_reset_engine calls
2007-01-04 6:42 ` Olaf Hering
@ 2007-01-04 10:53 ` Alan
0 siblings, 0 replies; 95+ messages in thread
From: Alan @ 2007-01-04 10:53 UTC (permalink / raw)
To: Olaf Hering; +Cc: linux-ide, linuxppc-dev
On Thu, 4 Jan 2007 07:42:54 +0100
Olaf Hering <olaf@aepfle.de> wrote:
> On Mon, Dec 04, Alan wrote:
>
> > On Mon, 4 Dec 2006 13:40:26 +0100 (MET)
> > Olaf Hering <olaf@aepfle.de> wrote:
> >
> > >
> > >
> > > the hald media changed polling does really confuse things.
> > > noone knows why the delays are needed, but they give us access to
> > > the CD.
> >
> > Can you tell me what happens if you completely pull the reset out of the
> > dma_end function. Do you still need delays then.
>
> An udelay(50) will give reliable access to the drive, but there is still
> one (or more) EH reset. The drive works without EH resets with udelay(100).
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Alan Cox <alan@redhat.com>
This wants revisiting some day to understand the interaction better but
for now it gets us up and running properly.
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: What is the correct way to indicate an unassigned PCI resource ?
2006-12-05 20:19 ` Benjamin Herrenschmidt
(?)
(?)
@ 2007-01-04 17:49 ` Olaf Hering
2007-01-04 21:30 ` Benjamin Herrenschmidt
-1 siblings, 1 reply; 95+ messages in thread
From: Olaf Hering @ 2007-01-04 17:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linux-ide, greg, linuxppc-dev, linux-pci, Alan
On Wed, Dec 06, Benjamin Herrenschmidt wrote:
> On Tue, 2006-12-05 at 09:15 +0100, Olaf Hering wrote:
> > On Tue, Dec 05, Benjamin Herrenschmidt wrote:
> >
> > > Olaf, can you give me a dump of /proc/ioports ? What is sitting at 0 on
> > > that PCI bus ?
> >
> > with IDE=y
> >
> > ==> /proc/ioports <==
> > 00000000-0000001f : dma1
>
> So it's indeed colliding with the cruft above.
>
> I reckon it's a bug in the firmware of this machine.
>
> Add to pseries/pci.c a quirk for that chipset (don't forget to test for
> machine_is(pseries) in the quirk as they get called for all platforms in
> a combo kernel. The quirk shall check if resource 6 has a 0 base and
> clear the size as Alan suggested (possibly setting the UNSET flag as
> well).
I will test this change tomorrow:
+++ linux-2.6/arch/powerpc/platforms/pseries/pci.c
@@ -98,6 +98,10 @@ static void fixup_winbond_82c105(struct
if (dev->resource[i].flags & IORESOURCE_IO
&& dev->bus->number == 0 && dev->devfn == 0x81)
dev->resource[i].flags &= ~IORESOURCE_IO;
+ if (dev->resource[i].start == 0) {
+ printk("disable IO resource %d on W82c105 IDE controller\n", i);
+ dev->resource[i].flags = IORESOURCE_DISABLED;
+ }
}
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_WINBOND, PCI_DEVICE_ID_WINBOND_82C105,
Or did you mean 'if (dev->resource[5].start == 0)' ?
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: What is the correct way to indicate an unassigned PCI resource ?
2007-01-04 17:49 ` Olaf Hering
@ 2007-01-04 21:30 ` Benjamin Herrenschmidt
2007-01-05 10:26 ` Olaf Hering
0 siblings, 1 reply; 95+ messages in thread
From: Benjamin Herrenschmidt @ 2007-01-04 21:30 UTC (permalink / raw)
To: Olaf Hering; +Cc: linux-ide, greg, linuxppc-dev, linux-pci, Alan
> > Add to pseries/pci.c a quirk for that chipset (don't forget to test for
> > machine_is(pseries) in the quirk as they get called for all platforms in
> > a combo kernel. The quirk shall check if resource 6 has a 0 base and
> > clear the size as Alan suggested (possibly setting the UNSET flag as
> > well).
>
> I will test this change tomorrow:
>
> +++ linux-2.6/arch/powerpc/platforms/pseries/pci.c
> @@ -98,6 +98,10 @@ static void fixup_winbond_82c105(struct
> if (dev->resource[i].flags & IORESOURCE_IO
> && dev->bus->number == 0 && dev->devfn == 0x81)
> dev->resource[i].flags &= ~IORESOURCE_IO;
> + if (dev->resource[i].start == 0) {
> + printk("disable IO resource %d on W82c105 IDE controller\n", i);
> + dev->resource[i].flags = IORESOURCE_DISABLED;
> + }
> }
> }
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_WINBOND, PCI_DEVICE_ID_WINBOND_82C105,
>
>
>
> Or did you mean 'if (dev->resource[5].start == 0)' ?
Nah, but also set resource->end = 0 too and or-in IORESOURCE_UNSET for
flags not (=) (or just set it to 0, I have no problem with completely
clearing the resource, that will keep it out of the way)
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: What is the correct way to indicate an unassigned PCI resource ?
2007-01-04 21:30 ` Benjamin Herrenschmidt
@ 2007-01-05 10:26 ` Olaf Hering
0 siblings, 0 replies; 95+ messages in thread
From: Olaf Hering @ 2007-01-05 10:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Alan, Sergei Shtylyov, linuxppc-dev, greg, linux-ide, linux-pci
On Fri, Jan 05, Benjamin Herrenschmidt wrote:
> Nah, but also set resource->end = 0 too and or-in IORESOURCE_UNSET for
> flags not (=) (or just set it to 0, I have no problem with completely
> clearing the resource, that will keep it out of the way)
I get this output with the change below:
Using INTC for W82c105 IDE controller.
W82c105: bn 0 dfn 19
00: f 0000000000000101 s 000000000000f000 e 000000000000f007
01: f 0000000000000101 s 000000000000f010 e 000000000000f013
02: f 0000000000000101 s 000000000000f020 e 000000000000f027
03: f 0000000000000101 s 000000000000f030 e 000000000000f033
04: f 0000000000000101 s 000000000000f040 e 000000000000f04f
05: f 0000000000000101 s 0000000000000000 e 000000000000000f
05: disable IO resource on W82c105 IDE controller
06: f 0000000000000000 s 0000000000000000 e 0000000000000000
07: f 0000000000000000 s 0000000000000000 e 0000000000000000
08: f 0000000000000000 s 0000000000000000 e 0000000000000000
09: f 0000000000000000 s 0000000000000000 e 0000000000000000
10: f 0000000000000000 s 0000000000000000 e 0000000000000000
11: f 0000000000000000 s 0000000000000000 e 0000000000000000
If thats ok, I will submit a patch without the printk.
@@ -130,11 +130,18 @@ static void fixup_winbond_82c105(struct
/* Enable LEGIRQ to use INTC instead of ISA interrupts */
pci_write_config_dword(dev, 0x40, reg | (1<<11));
+ printk("W82c105: bn %x dfn %x\n", dev->bus->number, dev->devfn);
for (i = 0; i < DEVICE_COUNT_RESOURCE; ++i) {
+ printk("%02d: f %016lx s %016lx e %016lx\n", i, dev->resource[i].flags, dev->resource[i].start, dev->resource[i].end);
/* zap the 2nd function of the winbond chip */
if (dev->resource[i].flags & IORESOURCE_IO
&& dev->bus->number == 0 && dev->devfn == 0x81)
dev->resource[i].flags &= ~IORESOURCE_IO;
+ if (dev->resource[i].start == 0 && dev->resource[i].end) {
+ printk("%02d: disable IO resource on W82c105 IDE controller\n", i);
+ dev->resource[i].flags = 0;
+ dev->resource[i].end = 0;
+ }
}
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_WINBOND, PCI_DEVICE_ID_WINBOND_82C105,
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: What is the correct way to indicate an unassigned PCI resource ?
@ 2007-01-05 10:26 ` Olaf Hering
0 siblings, 0 replies; 95+ messages in thread
From: Olaf Hering @ 2007-01-05 10:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linux-ide, greg, linuxppc-dev, linux-pci, Alan
On Fri, Jan 05, Benjamin Herrenschmidt wrote:
> Nah, but also set resource->end = 0 too and or-in IORESOURCE_UNSET for
> flags not (=) (or just set it to 0, I have no problem with completely
> clearing the resource, that will keep it out of the way)
I get this output with the change below:
Using INTC for W82c105 IDE controller.
W82c105: bn 0 dfn 19
00: f 0000000000000101 s 000000000000f000 e 000000000000f007
01: f 0000000000000101 s 000000000000f010 e 000000000000f013
02: f 0000000000000101 s 000000000000f020 e 000000000000f027
03: f 0000000000000101 s 000000000000f030 e 000000000000f033
04: f 0000000000000101 s 000000000000f040 e 000000000000f04f
05: f 0000000000000101 s 0000000000000000 e 000000000000000f
05: disable IO resource on W82c105 IDE controller
06: f 0000000000000000 s 0000000000000000 e 0000000000000000
07: f 0000000000000000 s 0000000000000000 e 0000000000000000
08: f 0000000000000000 s 0000000000000000 e 0000000000000000
09: f 0000000000000000 s 0000000000000000 e 0000000000000000
10: f 0000000000000000 s 0000000000000000 e 0000000000000000
11: f 0000000000000000 s 0000000000000000 e 0000000000000000
If thats ok, I will submit a patch without the printk.
@@ -130,11 +130,18 @@ static void fixup_winbond_82c105(struct
/* Enable LEGIRQ to use INTC instead of ISA interrupts */
pci_write_config_dword(dev, 0x40, reg | (1<<11));
+ printk("W82c105: bn %x dfn %x\n", dev->bus->number, dev->devfn);
for (i = 0; i < DEVICE_COUNT_RESOURCE; ++i) {
+ printk("%02d: f %016lx s %016lx e %016lx\n", i, dev->resource[i].flags, dev->resource[i].start, dev->resource[i].end);
/* zap the 2nd function of the winbond chip */
if (dev->resource[i].flags & IORESOURCE_IO
&& dev->bus->number == 0 && dev->devfn == 0x81)
dev->resource[i].flags &= ~IORESOURCE_IO;
+ if (dev->resource[i].start == 0 && dev->resource[i].end) {
+ printk("%02d: disable IO resource on W82c105 IDE controller\n", i);
+ dev->resource[i].flags = 0;
+ dev->resource[i].end = 0;
+ }
}
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_WINBOND, PCI_DEVICE_ID_WINBOND_82C105,
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: What is the correct way to indicate an unassigned PCI resource ?
2007-01-05 10:26 ` Olaf Hering
@ 2007-01-05 12:05 ` Benjamin Herrenschmidt
-1 siblings, 0 replies; 95+ messages in thread
From: Benjamin Herrenschmidt @ 2007-01-05 12:05 UTC (permalink / raw)
To: Olaf Hering
Cc: Alan, Sergei Shtylyov, linuxppc-dev, greg, linux-ide, linux-pci
On Fri, 2007-01-05 at 11:26 +0100, Olaf Hering wrote:
> On Fri, Jan 05, Benjamin Herrenschmidt wrote:
>
> > Nah, but also set resource->end = 0 too and or-in IORESOURCE_UNSET for
> > flags not (=) (or just set it to 0, I have no problem with completely
> > clearing the resource, that will keep it out of the way)
>
> I get this output with the change below:
>
> Using INTC for W82c105 IDE controller.
> W82c105: bn 0 dfn 19
> 00: f 0000000000000101 s 000000000000f000 e 000000000000f007
> 01: f 0000000000000101 s 000000000000f010 e 000000000000f013
> 02: f 0000000000000101 s 000000000000f020 e 000000000000f027
> 03: f 0000000000000101 s 000000000000f030 e 000000000000f033
> 04: f 0000000000000101 s 000000000000f040 e 000000000000f04f
> 05: f 0000000000000101 s 0000000000000000 e 000000000000000f
> 05: disable IO resource on W82c105 IDE controller
> 06: f 0000000000000000 s 0000000000000000 e 0000000000000000
> 07: f 0000000000000000 s 0000000000000000 e 0000000000000000
> 08: f 0000000000000000 s 0000000000000000 e 0000000000000000
> 09: f 0000000000000000 s 0000000000000000 e 0000000000000000
> 10: f 0000000000000000 s 0000000000000000 e 0000000000000000
> 11: f 0000000000000000 s 0000000000000000 e 0000000000000000
>
> If thats ok, I will submit a patch without the printk.
If it works, I'm fine with it.
Ben.
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: What is the correct way to indicate an unassigned PCI resource ?
@ 2007-01-05 12:05 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 95+ messages in thread
From: Benjamin Herrenschmidt @ 2007-01-05 12:05 UTC (permalink / raw)
To: Olaf Hering; +Cc: linux-ide, greg, linuxppc-dev, linux-pci, Alan
On Fri, 2007-01-05 at 11:26 +0100, Olaf Hering wrote:
> On Fri, Jan 05, Benjamin Herrenschmidt wrote:
>
> > Nah, but also set resource->end = 0 too and or-in IORESOURCE_UNSET for
> > flags not (=) (or just set it to 0, I have no problem with completely
> > clearing the resource, that will keep it out of the way)
>
> I get this output with the change below:
>
> Using INTC for W82c105 IDE controller.
> W82c105: bn 0 dfn 19
> 00: f 0000000000000101 s 000000000000f000 e 000000000000f007
> 01: f 0000000000000101 s 000000000000f010 e 000000000000f013
> 02: f 0000000000000101 s 000000000000f020 e 000000000000f027
> 03: f 0000000000000101 s 000000000000f030 e 000000000000f033
> 04: f 0000000000000101 s 000000000000f040 e 000000000000f04f
> 05: f 0000000000000101 s 0000000000000000 e 000000000000000f
> 05: disable IO resource on W82c105 IDE controller
> 06: f 0000000000000000 s 0000000000000000 e 0000000000000000
> 07: f 0000000000000000 s 0000000000000000 e 0000000000000000
> 08: f 0000000000000000 s 0000000000000000 e 0000000000000000
> 09: f 0000000000000000 s 0000000000000000 e 0000000000000000
> 10: f 0000000000000000 s 0000000000000000 e 0000000000000000
> 11: f 0000000000000000 s 0000000000000000 e 0000000000000000
>
> If thats ok, I will submit a patch without the printk.
If it works, I'm fine with it.
Ben.
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH] mark PCI resource with start 0 as unassigned
2006-12-04 13:25 ` Segher Boessenkool
@ 2007-08-01 14:22 ` Sergei Shtylyov
-1 siblings, 0 replies; 95+ messages in thread
From: Sergei Shtylyov @ 2007-08-01 14:22 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Alan, Olaf Hering, linux-ide, linuxppc-dev
Segher Boessenkool wrote:
>> setup-pci is for SFF8038i devices. It therefore knows that for assigned
>> resources they must be I/O. It also assumes that zero is not a valid I/O
>> port just like zero is not a valid IRQ. Stick a real IDE resource at
>> zero and drivers/ide can't cope.
> But 0 _is_ a valid PCI I/O address. Do we now have to start
I wasn't in PCI 2.1 (later the corresponding passage have disppeared).
> using "virtual I/O addresses", analogue to the IRQ situation,
> or can these bad assumptions be fixed instead?
> Segher
WBR, Sergei
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH] mark PCI resource with start 0 as unassigned
@ 2007-08-01 14:22 ` Sergei Shtylyov
0 siblings, 0 replies; 95+ messages in thread
From: Sergei Shtylyov @ 2007-08-01 14:22 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linux-ide, Olaf Hering, Alan, linuxppc-dev
Segher Boessenkool wrote:
>> setup-pci is for SFF8038i devices. It therefore knows that for assigned
>> resources they must be I/O. It also assumes that zero is not a valid I/O
>> port just like zero is not a valid IRQ. Stick a real IDE resource at
>> zero and drivers/ide can't cope.
> But 0 _is_ a valid PCI I/O address. Do we now have to start
I wasn't in PCI 2.1 (later the corresponding passage have disppeared).
> using "virtual I/O addresses", analogue to the IRQ situation,
> or can these bad assumptions be fixed instead?
> Segher
WBR, Sergei
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH] mark PCI resource with start 0 as unassigned
2007-08-01 14:22 ` Sergei Shtylyov
@ 2007-08-01 15:51 ` Alan Cox
-1 siblings, 0 replies; 95+ messages in thread
From: Alan Cox @ 2007-08-01 15:51 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: Segher Boessenkool, Olaf Hering, linux-ide, linuxppc-dev
On Wed, 01 Aug 2007 18:22:36 +0400
Sergei Shtylyov <sshtylyov@ru.mvista.com> wrote:
> Segher Boessenkool wrote:
>
> >> setup-pci is for SFF8038i devices. It therefore knows that for assigned
> >> resources they must be I/O. It also assumes that zero is not a valid I/O
> >> port just like zero is not a valid IRQ. Stick a real IDE resource at
> >> zero and drivers/ide can't cope.
>
> > But 0 _is_ a valid PCI I/O address. Do we now have to start
>
> I wasn't in PCI 2.1 (later the corresponding passage have disppeared).
SFF controllers often use 0 to indicate a channel isn't configured and
present. Libata and old IDE both assume these semantics for an SFF
IDE device reporting address zero. It matches the hardware behaviour.
I would suggest you don't map one at I/O zero on your PCI.
Alan
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH] mark PCI resource with start 0 as unassigned
@ 2007-08-01 15:51 ` Alan Cox
0 siblings, 0 replies; 95+ messages in thread
From: Alan Cox @ 2007-08-01 15:51 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linux-ide, Olaf Hering, linuxppc-dev
On Wed, 01 Aug 2007 18:22:36 +0400
Sergei Shtylyov <sshtylyov@ru.mvista.com> wrote:
> Segher Boessenkool wrote:
>
> >> setup-pci is for SFF8038i devices. It therefore knows that for assigned
> >> resources they must be I/O. It also assumes that zero is not a valid I/O
> >> port just like zero is not a valid IRQ. Stick a real IDE resource at
> >> zero and drivers/ide can't cope.
>
> > But 0 _is_ a valid PCI I/O address. Do we now have to start
>
> I wasn't in PCI 2.1 (later the corresponding passage have disppeared).
SFF controllers often use 0 to indicate a channel isn't configured and
present. Libata and old IDE both assume these semantics for an SFF
IDE device reporting address zero. It matches the hardware behaviour.
I would suggest you don't map one at I/O zero on your PCI.
Alan
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH] mark PCI resource with start 0 as unassigned
2007-08-01 15:51 ` Alan Cox
@ 2007-08-06 18:04 ` Segher Boessenkool
-1 siblings, 0 replies; 95+ messages in thread
From: Segher Boessenkool @ 2007-08-06 18:04 UTC (permalink / raw)
To: Alan Cox; +Cc: Olaf Hering, linuxppc-dev, Sergei Shtylyov, linux-ide
>>> But 0 _is_ a valid PCI I/O address. Do we now have to start
>>
>> I wasn't in PCI 2.1 (later the corresponding passage have
>> disppeared).
>
> SFF controllers often use 0 to indicate a channel isn't configured and
> present. Libata and old IDE both assume these semantics for an SFF
> IDE device reporting address zero. It matches the hardware behaviour.
>
> I would suggest you don't map one at I/O zero on your PCI.
That's of course the smarter choice, _if_ we have a choice at
all -- on PowerPC, the PCI setup on certain platforms is done
by the firmware (and we don't want to mess with it for various
reasons), and some _do_ map PCI legacy I/O at 0.
Not in this case though, so let's just ignore that possibility
until it hits us in the face :-)
Segher
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH] mark PCI resource with start 0 as unassigned
@ 2007-08-06 18:04 ` Segher Boessenkool
0 siblings, 0 replies; 95+ messages in thread
From: Segher Boessenkool @ 2007-08-06 18:04 UTC (permalink / raw)
To: Alan Cox; +Cc: linuxppc-dev, Olaf Hering, linux-ide
>>> But 0 _is_ a valid PCI I/O address. Do we now have to start
>>
>> I wasn't in PCI 2.1 (later the corresponding passage have
>> disppeared).
>
> SFF controllers often use 0 to indicate a channel isn't configured and
> present. Libata and old IDE both assume these semantics for an SFF
> IDE device reporting address zero. It matches the hardware behaviour.
>
> I would suggest you don't map one at I/O zero on your PCI.
That's of course the smarter choice, _if_ we have a choice at
all -- on PowerPC, the PCI setup on certain platforms is done
by the firmware (and we don't want to mess with it for various
reasons), and some _do_ map PCI legacy I/O at 0.
Not in this case though, so let's just ignore that possibility
until it hits us in the face :-)
Segher
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH] mark PCI resource with start 0 as unassigned
2007-08-06 18:04 ` Segher Boessenkool
@ 2007-08-06 19:52 ` Alan Cox
-1 siblings, 0 replies; 95+ messages in thread
From: Alan Cox @ 2007-08-06 19:52 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Olaf Hering, linuxppc-dev, Sergei Shtylyov, linux-ide
O> That's of course the smarter choice, _if_ we have a choice at
> all -- on PowerPC, the PCI setup on certain platforms is done
> by the firmware (and we don't want to mess with it for various
> reasons), and some _do_ map PCI legacy I/O at 0.
>
> Not in this case though, so let's just ignore that possibility
> until it hits us in the face :-)
An SFF controller mapped at I/O is basically not going to work. Take it
up with the firmware
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH] mark PCI resource with start 0 as unassigned
@ 2007-08-06 19:52 ` Alan Cox
0 siblings, 0 replies; 95+ messages in thread
From: Alan Cox @ 2007-08-06 19:52 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Olaf Hering, linux-ide
O> That's of course the smarter choice, _if_ we have a choice at
> all -- on PowerPC, the PCI setup on certain platforms is done
> by the firmware (and we don't want to mess with it for various
> reasons), and some _do_ map PCI legacy I/O at 0.
>
> Not in this case though, so let's just ignore that possibility
> until it hits us in the face :-)
An SFF controller mapped at I/O is basically not going to work. Take it
up with the firmware
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH] mark PCI resource with start 0 as unassigned
2007-08-06 18:04 ` Segher Boessenkool
@ 2007-08-06 22:14 ` Benjamin Herrenschmidt
-1 siblings, 0 replies; 95+ messages in thread
From: Benjamin Herrenschmidt @ 2007-08-06 22:14 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Alan Cox, linuxppc-dev, Olaf Hering, linux-ide
On Mon, 2007-08-06 at 20:04 +0200, Segher Boessenkool wrote:
> That's of course the smarter choice, _if_ we have a choice at
> all -- on PowerPC, the PCI setup on certain platforms is done
> by the firmware (and we don't want to mess with it for various
> reasons), and some _do_ map PCI legacy I/O at 0.
>
> Not in this case though, so let's just ignore that possibility
> until it hits us in the face :-)
Agreed. We can always try to remap just that device if it becomes an
issue.
Ben.
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH] mark PCI resource with start 0 as unassigned
@ 2007-08-06 22:14 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 95+ messages in thread
From: Benjamin Herrenschmidt @ 2007-08-06 22:14 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Olaf Hering, Alan Cox, linux-ide
On Mon, 2007-08-06 at 20:04 +0200, Segher Boessenkool wrote:
> That's of course the smarter choice, _if_ we have a choice at
> all -- on PowerPC, the PCI setup on certain platforms is done
> by the firmware (and we don't want to mess with it for various
> reasons), and some _do_ map PCI legacy I/O at 0.
>
> Not in this case though, so let's just ignore that possibility
> until it hits us in the face :-)
Agreed. We can always try to remap just that device if it becomes an
issue.
Ben.
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH] add delay around sl82c105_reset_engine calls
2007-02-10 20:36 ` [PATCH] add delay around sl82c105_reset_engine calls Olaf Hering
@ 2007-02-15 23:09 ` Jeff Garzik
0 siblings, 0 replies; 95+ messages in thread
From: Jeff Garzik @ 2007-02-15 23:09 UTC (permalink / raw)
To: Olaf Hering; +Cc: Andrew Morton, linuxppc-dev, linux-ide
Olaf Hering wrote:
> The hald media changed polling does really confuse things.
> Noone knows why the delays are needed, but they give us access to the CD.
>
> An udelay(50) will give reliable access to the drive, but there is still
> one (or more) EH reset. The drive works without EH resets with udelay(100).
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
>
> ---
> drivers/ata/pata_sl82c105.c | 3 +++
> 1 file changed, 3 insertions(+)
applied
^ permalink raw reply [flat|nested] 95+ messages in thread
* [PATCH] add delay around sl82c105_reset_engine calls
2007-02-10 20:35 [PATCH] move variables in drivers/macintosh to bss Olaf Hering
@ 2007-02-10 20:36 ` Olaf Hering
2007-02-15 23:09 ` Jeff Garzik
0 siblings, 1 reply; 95+ messages in thread
From: Olaf Hering @ 2007-02-10 20:36 UTC (permalink / raw)
To: linuxppc-dev, Andrew Morton; +Cc: linux-ide
The hald media changed polling does really confuse things.
Noone knows why the delays are needed, but they give us access to the CD.
An udelay(50) will give reliable access to the drive, but there is still
one (or more) EH reset. The drive works without EH resets with udelay(100).
Signed-off-by: Olaf Hering <olaf@aepfle.de>
---
drivers/ata/pata_sl82c105.c | 3 +++
1 file changed, 3 insertions(+)
Index: linux-2.6/drivers/ata/pata_sl82c105.c
===================================================================
--- linux-2.6.orig/drivers/ata/pata_sl82c105.c
+++ linux-2.6/drivers/ata/pata_sl82c105.c
@@ -187,7 +187,9 @@ static void sl82c105_bmdma_start(struct
{
struct ata_port *ap = qc->ap;
+ udelay(100);
sl82c105_reset_engine(ap);
+ udelay(100);
/* Set the clocks for DMA */
sl82c105_configure_dmamode(ap, qc->dev);
@@ -216,6 +218,7 @@ static void sl82c105_bmdma_stop(struct a
ata_bmdma_stop(qc);
sl82c105_reset_engine(ap);
+ udelay(100);
/* This will redo the initial setup of the DMA device to matching
PIO timings */
^ permalink raw reply [flat|nested] 95+ messages in thread
end of thread, other threads:[~2007-08-06 22:14 UTC | newest]
Thread overview: 95+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-11-30 16:52 pata_sl82c105 can not reserve IO region Olaf Hering
2006-11-30 17:10 ` Alan
2006-11-30 18:47 ` Olaf Hering
2006-12-01 18:34 ` Olaf Hering
2006-12-01 18:58 ` Alan
2006-12-01 19:05 ` Sergei Shtylyov
2006-12-01 19:05 ` Sergei Shtylyov
2006-12-01 21:53 ` Benjamin Herrenschmidt
2006-12-01 21:53 ` Benjamin Herrenschmidt
2006-12-01 22:15 ` Alan
2006-12-01 22:15 ` Alan
2006-12-01 22:19 ` Benjamin Herrenschmidt
2006-12-01 22:19 ` Benjamin Herrenschmidt
2006-12-02 14:36 ` U-Boot allocating PCI I/O space from 0 (Was: pata_sl82c105 can not reserve IO region) Sergei Shtylyov
2006-12-02 14:36 ` [U-Boot-Users] " Sergei Shtylyov
2006-12-02 16:33 ` Sergei Shtylyov
2006-12-02 16:33 ` [U-Boot-Users] " Sergei Shtylyov
2006-12-26 20:53 ` Sergei Shtylyov
2006-12-26 20:53 ` Sergei Shtylyov
2006-12-03 23:39 ` pata_sl82c105 can not reserve IO region Alan
2006-12-03 23:39 ` Alan
2006-12-03 17:12 ` Olaf Hering
2006-12-03 22:24 ` Olaf Hering
2006-12-03 23:23 ` Alan
2006-12-04 0:30 ` Olaf Hering
2006-12-04 9:21 ` Olaf Hering
2006-12-03 23:07 ` Alan
2006-12-04 12:38 ` [PATCH] mark PCI resource with start 0 as unassigned Olaf Hering
2006-12-04 12:44 ` Segher Boessenkool
2006-12-04 12:50 ` Sergei Shtylyov
2006-12-04 12:50 ` Sergei Shtylyov
2006-12-04 12:54 ` Segher Boessenkool
2006-12-04 12:54 ` Segher Boessenkool
2006-12-04 13:08 ` Sergei Shtylyov
2006-12-04 13:08 ` Sergei Shtylyov
2006-12-04 13:21 ` Alan
2006-12-04 13:25 ` Segher Boessenkool
2006-12-04 13:25 ` Segher Boessenkool
2006-12-04 14:15 ` Alan
2007-08-01 14:22 ` Sergei Shtylyov
2007-08-01 14:22 ` Sergei Shtylyov
2007-08-01 15:51 ` Alan Cox
2007-08-01 15:51 ` Alan Cox
2007-08-06 18:04 ` Segher Boessenkool
2007-08-06 18:04 ` Segher Boessenkool
2007-08-06 19:52 ` Alan Cox
2007-08-06 19:52 ` Alan Cox
2007-08-06 22:14 ` Benjamin Herrenschmidt
2007-08-06 22:14 ` Benjamin Herrenschmidt
2006-12-04 13:27 ` Sergei Shtylyov
2006-12-04 13:27 ` Sergei Shtylyov
2006-12-04 14:22 ` What is the correct way to indicate an unassigned PCI resource ? Alan
2006-12-04 14:34 ` Sergei Shtylyov
2006-12-04 14:34 ` Sergei Shtylyov
2006-12-04 14:44 ` Alan
2006-12-04 15:40 ` Sergei Shtylyov
2006-12-04 15:40 ` Sergei Shtylyov
2006-12-04 15:55 ` Sergei Shtylyov
2006-12-04 15:55 ` Sergei Shtylyov
2006-12-04 20:53 ` Guennadi Liakhovetski
2006-12-04 20:53 ` Guennadi Liakhovetski
2006-12-05 4:43 ` Benjamin Herrenschmidt
2006-12-05 4:43 ` Benjamin Herrenschmidt
2006-12-05 4:41 ` Benjamin Herrenschmidt
2006-12-05 4:41 ` Benjamin Herrenschmidt
2006-12-05 8:15 ` Olaf Hering
2006-12-05 8:15 ` Olaf Hering
2006-12-05 20:19 ` Benjamin Herrenschmidt
2006-12-05 20:19 ` Benjamin Herrenschmidt
2006-12-05 21:26 ` Sergei Shtylyov
2006-12-05 21:26 ` Sergei Shtylyov
2007-01-04 17:49 ` Olaf Hering
2007-01-04 21:30 ` Benjamin Herrenschmidt
2007-01-05 10:26 ` Olaf Hering
2007-01-05 10:26 ` Olaf Hering
2007-01-05 12:05 ` Benjamin Herrenschmidt
2007-01-05 12:05 ` Benjamin Herrenschmidt
2006-12-05 10:51 ` Gabriel Paubert
2006-12-05 10:51 ` Gabriel Paubert
2006-12-05 12:38 ` Sergei Shtylyov
2006-12-05 12:38 ` Sergei Shtylyov
2006-12-05 17:37 ` Grant Grundler
2006-12-05 17:37 ` Grant Grundler
2006-12-05 19:22 ` Sergei Shtylyov
2006-12-05 19:22 ` Sergei Shtylyov
2006-12-04 12:56 ` [PATCH] mark PCI resource with start 0 as unassigned Olaf Hering
2006-12-04 13:05 ` Segher Boessenkool
2006-12-04 12:47 ` Sergei Shtylyov
2006-12-04 12:40 ` [PATCH] add delay around sl82c105_reset_engine calls Olaf Hering
2006-12-04 13:02 ` Alan
2006-12-04 13:12 ` Olaf Hering
2007-01-04 6:42 ` Olaf Hering
2007-01-04 10:53 ` Alan
2007-02-10 20:35 [PATCH] move variables in drivers/macintosh to bss Olaf Hering
2007-02-10 20:36 ` [PATCH] add delay around sl82c105_reset_engine calls Olaf Hering
2007-02-15 23:09 ` Jeff Garzik
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.