linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Yenta Cardbus allocation failure
@ 2006-12-12  8:04 Markus Rechberger
  2006-12-19  0:12 ` [solved] " Markus Rechberger
  0 siblings, 1 reply; 4+ messages in thread
From: Markus Rechberger @ 2006-12-12  8:04 UTC (permalink / raw)
  To: linux-kernel

Hi,

I've got a PCMCIA Hybrid TV tuner, but when I plug it in it fails to
allocate resources for the 3rd PCI function.
I already searched with google and someone implemented an otion

parm:           override_bios:yenta ignore bios resource allocation (uint

in yenta_socket, though this doesn't seem to work out with that device.

Any idea how that problem can be solved?

So here are some logs

lspci:
0000:03:00.0 Multimedia video controller: Conexant CX23880/1/2/3 PCI
Video and Audio Decoder (rev 05)
        Subsystem: Yuan Yuan Enterprise Co., Ltd.: Unknown device 1788
        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: 64 (5000ns min, 13750ns max)
        Interrupt: pin A routed to IRQ 10
        Region 0: Memory at 36000000 (32-bit, non-prefetchable) [size=16M]
        Capabilities: [44] Vital Product Data
        Capabilities: [4c] 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-

0000:03:00.1 Multimedia controller: Conexant CX23880/1/2/3 PCI Video
and Audio Decoder [Audio Port] (rev 05)
        Subsystem: Yuan Yuan Enterprise Co., Ltd.: Unknown device 1788
        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: 64 (1000ns min, 63750ns max)
        Interrupt: pin A routed to IRQ 10
        Region 0: Memory at 37000000 (32-bit, non-prefetchable) [size=16M]
        Capabilities: [4c] 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-

0000:03:00.2 Multimedia controller: Conexant CX23880/1/2/3 PCI Video
and Audio Decoder [MPEG Port] (rev 05)
        Subsystem: Yuan Yuan Enterprise Co., Ltd.: Unknown device 1788
        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 10
        Capabilities: [4c] 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-


cat /proc/iomem
00000000-0009f7ff : System RAM
0009f800-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000ccdff : Video ROM
000cd000-000ce7ff : Adapter ROM
000f0000-000fffff : System ROM
00100000-1dedffff : System RAM
  00100000-002ada17 : Kernel code
  002ada18-0037ebc7 : Kernel data
1dee0000-1deebfff : ACPI Tables
1deec000-1defffff : ACPI Non-volatile Storage
1df00000-1fffffff : reserved
30000000-33ffffff : PCI Bus #02
  30000000-31ffffff : PCI CardBus #03
  32000000-33ffffff : PCI CardBus #07
34000000-340003ff : 0000:00:1f.1
36000000-37ffffff : PCI CardBus #03
  36000000-36ffffff : 0000:03:00.0
    36000000-36ffffff : cx88[0]
  37000000-37ffffff : 0000:03:00.1
    37000000-37ffffff : cx88[0]
38000000-39ffffff : PCI CardBus #07
e0000000-e007ffff : 0000:00:02.0
e0080000-e00fffff : 0000:00:02.1
e0100000-e01003ff : 0000:00:1d.7
  e0100000-e01003ff : ehci_hcd
e0100800-e01008ff : 0000:00:1f.5
  e0100800-e01008ff : Intel 82801DB-ICH4
e0100c00-e0100dff : 0000:00:1f.5
  e0100c00-e0100dff : Intel 82801DB-ICH4
e0200000-e07fffff : PCI Bus #02
  e0200000-e0203fff : 0000:02:07.0
  e0204000-e0205fff : 0000:02:02.0
    e0204000-e0205fff : b44
  e0206000-e0206fff : 0000:02:04.0
    e0206000-e0206fff : ipw2100
  e0207000-e0207fff : 0000:02:06.0
    e0207000-e0207fff : yenta_socket
  e0208000-e0208fff : 0000:02:06.1
    e0208000-e0208fff : yenta_socket
  e0209000-e02097ff : 0000:02:07.0
    e0209000-e02097ff : ohci1394
  e0260000-e0260fff : pcmcia_socket1
e8000000-efffffff : 0000:00:02.0
f0000000-f7ffffff : 0000:00:02.1
fec10000-fec1ffff : reserved
ff800000-ffbfffff : reserved
fffffc00-ffffffff : reserved



dmesg:
Yenta: CardBus bridge found at 0000:02:06.0 [1025:0035]
Yenta O2: res at 0x94/0xD4: 00/ea
Yenta O2: enabling read prefetch/write burst
Yenta: ISA IRQ mask 0x00b8, PCI irq 10
Socket status: 30000820
Yenta: Raising subordinate bus# of parent bus (#02) from #02 to #06
pcmcia: parent PCI bridge I/O window: 0x3000 - 0x3fff
cs: IO port probe 0x3000-0x3fff: clean.
pcmcia: parent PCI bridge Memory window: 0xe0200000 - 0xe07fffff
pcmcia: parent PCI bridge Memory window: 0x30000000 - 0x33ffffff
Yenta: CardBus bridge found at 0000:02:06.1 [1025:0035]
Yenta: ISA IRQ mask 0x00b8, PCI irq 10
Socket status: 30000410
Yenta: Raising subordinate bus# of parent bus (#02) from #06 to #0a
pcmcia: parent PCI bridge I/O window: 0x3000 - 0x3fff
cs: IO port probe 0x3000-0x3fff: clean.
pcmcia: parent PCI bridge Memory window: 0xe0200000 - 0xe07fffff
pcmcia: parent PCI bridge Memory window: 0x30000000 - 0x33ffffff
pccard: CardBus card inserted into slot 0
PCI: Failed to allocate mem resource #0:1000000@38000000 for 0000:03:00.2


thanks,
Markus

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [solved] Yenta Cardbus allocation failure
  2006-12-12  8:04 Yenta Cardbus allocation failure Markus Rechberger
@ 2006-12-19  0:12 ` Markus Rechberger
  2006-12-21  3:40   ` Andrew Morton
  0 siblings, 1 reply; 4+ messages in thread
From: Markus Rechberger @ 2006-12-19  0:12 UTC (permalink / raw)
  To: linux-kernel

I went on with investigating that problem and found the problem,
though I'm not sure if that solution is acceptable..

seems like the memory range gets preallocated in setup-bus.c, and
CARDBUS_MEM_SIZE defines that size.

I changed
#define CARDBUS_MEM_SIZE        (32*1024*1024)
to
#define CARDBUS_MEM_SIZE        (48*1024*1024)

and now the system is able to allocate the resources for the 3rd
pci/pcmcia function.

Can anyone please have a closer look at it too? I think the whole
implementation isn't really good there..

so this is the new output of iomem:
$ cat /proc/iomem
...
30000000-35ffffff : PCI Bus #02
  30000000-32ffffff : PCI CardBus #03
36000000-360003ff : 0000:00:1f.1
39000000-3bffffff : PCI CardBus #03
  39000000-39ffffff : 0000:03:00.0
  3a000000-3affffff : 0000:03:00.1
  3b000000-3bffffff : 0000:03:00.2 <- this one failed to allocate previously
3c000000-3effffff : PCI CardBus #07
41000000-43ffffff : PCI CardBus #07
...

and lspci:
$ lspci -vvv
03:00.0 Multimedia video controller: Conexant CX23880/1/2/3 PCI Video
and Audio Decoder (rev 05)
        Subsystem: Yuan Yuan Enterprise Co., Ltd. Unknown device 1788
        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 10
        Region 0: Memory at 39000000 (32-bit, non-prefetchable)
[disabled] [size=16M]
        Capabilities: [44] Vital Product Data
        Capabilities: [4c] 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-

03:00.1 Multimedia controller: Conexant CX23880/1/2/3 PCI Video and
Audio Decoder [Audio Port] (rev 05)
        Subsystem: Yuan Yuan Enterprise Co., Ltd. Unknown device 1788
        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 10
        Region 0: Memory at 3a000000 (32-bit, non-prefetchable)
[disabled] [size=16M]
        Capabilities: [4c] 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-

03:00.2 Multimedia controller: Conexant CX23880/1/2/3 PCI Video and
Audio Decoder [MPEG Port] (rev 05)
        Subsystem: Yuan Yuan Enterprise Co., Ltd. Unknown device 1788
        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 10
NEW --> Region 0: Memory at 3b000000 (32-bit, non-prefetchable)
[disabled] [size=16M]
        Capabilities: [4c] 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-


thanks,
Markus

On 12/12/06, Markus Rechberger <mrechberger@gmail.com> wrote:
> Hi,
>
> I've got a PCMCIA Hybrid TV tuner, but when I plug it in it fails to
> allocate resources for the 3rd PCI function.
> I already searched with google and someone implemented an otion
>
> parm:           override_bios:yenta ignore bios resource allocation (uint
>
> in yenta_socket, though this doesn't seem to work out with that device.
>
> Any idea how that problem can be solved?
>
> So here are some logs
>
> lspci:
> 0000:03:00.0 Multimedia video controller: Conexant CX23880/1/2/3 PCI
> Video and Audio Decoder (rev 05)
>         Subsystem: Yuan Yuan Enterprise Co., Ltd.: Unknown device 1788
>         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: 64 (5000ns min, 13750ns max)
>         Interrupt: pin A routed to IRQ 10
>         Region 0: Memory at 36000000 (32-bit, non-prefetchable) [size=16M]
>         Capabilities: [44] Vital Product Data
>         Capabilities: [4c] 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-
>
> 0000:03:00.1 Multimedia controller: Conexant CX23880/1/2/3 PCI Video
> and Audio Decoder [Audio Port] (rev 05)
>         Subsystem: Yuan Yuan Enterprise Co., Ltd.: Unknown device 1788
>         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: 64 (1000ns min, 63750ns max)
>         Interrupt: pin A routed to IRQ 10
>         Region 0: Memory at 37000000 (32-bit, non-prefetchable) [size=16M]
>         Capabilities: [4c] 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-
>
> 0000:03:00.2 Multimedia controller: Conexant CX23880/1/2/3 PCI Video
> and Audio Decoder [MPEG Port] (rev 05)
>         Subsystem: Yuan Yuan Enterprise Co., Ltd.: Unknown device 1788
>         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 10
>         Capabilities: [4c] 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-
>
>
> cat /proc/iomem
> 00000000-0009f7ff : System RAM
> 0009f800-0009ffff : reserved
> 000a0000-000bffff : Video RAM area
> 000c0000-000ccdff : Video ROM
> 000cd000-000ce7ff : Adapter ROM
> 000f0000-000fffff : System ROM
> 00100000-1dedffff : System RAM
>   00100000-002ada17 : Kernel code
>   002ada18-0037ebc7 : Kernel data
> 1dee0000-1deebfff : ACPI Tables
> 1deec000-1defffff : ACPI Non-volatile Storage
> 1df00000-1fffffff : reserved
> 30000000-33ffffff : PCI Bus #02
>   30000000-31ffffff : PCI CardBus #03
>   32000000-33ffffff : PCI CardBus #07
> 34000000-340003ff : 0000:00:1f.1
> 36000000-37ffffff : PCI CardBus #03
>   36000000-36ffffff : 0000:03:00.0
>     36000000-36ffffff : cx88[0]
>   37000000-37ffffff : 0000:03:00.1
>     37000000-37ffffff : cx88[0]
> 38000000-39ffffff : PCI CardBus #07
> e0000000-e007ffff : 0000:00:02.0
> e0080000-e00fffff : 0000:00:02.1
> e0100000-e01003ff : 0000:00:1d.7
>   e0100000-e01003ff : ehci_hcd
> e0100800-e01008ff : 0000:00:1f.5
>   e0100800-e01008ff : Intel 82801DB-ICH4
> e0100c00-e0100dff : 0000:00:1f.5
>   e0100c00-e0100dff : Intel 82801DB-ICH4
> e0200000-e07fffff : PCI Bus #02
>   e0200000-e0203fff : 0000:02:07.0
>   e0204000-e0205fff : 0000:02:02.0
>     e0204000-e0205fff : b44
>   e0206000-e0206fff : 0000:02:04.0
>     e0206000-e0206fff : ipw2100
>   e0207000-e0207fff : 0000:02:06.0
>     e0207000-e0207fff : yenta_socket
>   e0208000-e0208fff : 0000:02:06.1
>     e0208000-e0208fff : yenta_socket
>   e0209000-e02097ff : 0000:02:07.0
>     e0209000-e02097ff : ohci1394
>   e0260000-e0260fff : pcmcia_socket1
> e8000000-efffffff : 0000:00:02.0
> f0000000-f7ffffff : 0000:00:02.1
> fec10000-fec1ffff : reserved
> ff800000-ffbfffff : reserved
> fffffc00-ffffffff : reserved
>
>
>
> dmesg:
> Yenta: CardBus bridge found at 0000:02:06.0 [1025:0035]
> Yenta O2: res at 0x94/0xD4: 00/ea
> Yenta O2: enabling read prefetch/write burst
> Yenta: ISA IRQ mask 0x00b8, PCI irq 10
> Socket status: 30000820
> Yenta: Raising subordinate bus# of parent bus (#02) from #02 to #06
> pcmcia: parent PCI bridge I/O window: 0x3000 - 0x3fff
> cs: IO port probe 0x3000-0x3fff: clean.
> pcmcia: parent PCI bridge Memory window: 0xe0200000 - 0xe07fffff
> pcmcia: parent PCI bridge Memory window: 0x30000000 - 0x33ffffff
> Yenta: CardBus bridge found at 0000:02:06.1 [1025:0035]
> Yenta: ISA IRQ mask 0x00b8, PCI irq 10
> Socket status: 30000410
> Yenta: Raising subordinate bus# of parent bus (#02) from #06 to #0a
> pcmcia: parent PCI bridge I/O window: 0x3000 - 0x3fff
> cs: IO port probe 0x3000-0x3fff: clean.
> pcmcia: parent PCI bridge Memory window: 0xe0200000 - 0xe07fffff
> pcmcia: parent PCI bridge Memory window: 0x30000000 - 0x33ffffff
> pccard: CardBus card inserted into slot 0
> PCI: Failed to allocate mem resource #0:1000000@38000000 for 0000:03:00.2
>
>
> thanks,
> Markus
>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [solved] Yenta Cardbus allocation failure
  2006-12-19  0:12 ` [solved] " Markus Rechberger
@ 2006-12-21  3:40   ` Andrew Morton
  2006-12-21  7:07     ` Linus Torvalds
  0 siblings, 1 reply; 4+ messages in thread
From: Andrew Morton @ 2006-12-21  3:40 UTC (permalink / raw)
  To: Markus Rechberger
  Cc: linux-kernel, Linus Torvalds, Daniel Ritz, Dominik Brodowski

On Tue, 19 Dec 2006 01:12:07 +0100
"Markus Rechberger" <mrechberger@gmail.com> wrote:

> I went on with investigating that problem and found the problem,
> though I'm not sure if that solution is acceptable..
> 
> seems like the memory range gets preallocated in setup-bus.c, and
> CARDBUS_MEM_SIZE defines that size.
> 
> I changed
> #define CARDBUS_MEM_SIZE        (32*1024*1024)
> to
> #define CARDBUS_MEM_SIZE        (48*1024*1024)
> 
> and now the system is able to allocate the resources for the 3rd
> pci/pcmcia function.
> 
> Can anyone please have a closer look at it too? I think the whole
> implementation isn't really good there..
> 
> so this is the new output of iomem:
> $ cat /proc/iomem
> ...
> 30000000-35ffffff : PCI Bus #02
>   30000000-32ffffff : PCI CardBus #03
> 36000000-360003ff : 0000:00:1f.1
> 39000000-3bffffff : PCI CardBus #03
>   39000000-39ffffff : 0000:03:00.0
>   3a000000-3affffff : 0000:03:00.1
>   3b000000-3bffffff : 0000:03:00.2 <- this one failed to allocate previously
> 3c000000-3effffff : PCI CardBus #07
> 41000000-43ffffff : PCI CardBus #07
> ...

This keeps happening.  Is there no way in which we can put this to bed
permanently, or does it require prior knowledge about what cardbus cards
the user owns?

Does the cardbus spec set an upper limit on these resource sizes?

Linus has wondered "how much does Windows use"?  How might we determine
that?

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [solved] Yenta Cardbus allocation failure
  2006-12-21  3:40   ` Andrew Morton
@ 2006-12-21  7:07     ` Linus Torvalds
  0 siblings, 0 replies; 4+ messages in thread
From: Linus Torvalds @ 2006-12-21  7:07 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Markus Rechberger, linux-kernel, Daniel Ritz, Dominik Brodowski



On Wed, 20 Dec 2006, Andrew Morton wrote:
> 
> Linus has wondered "how much does Windows use"?  How might we determine
> that?

Google knows everything, and finds, on MS own site no less:

  "Windows 2000 default resources:

   One 4K memory window

   One 2 MB memory window

   Two 256-byte I/O windows"

which is clearly utterly bogus and insufficient. But Microsoft apparently 
realized this, and:

  "Windows XP default resources:

   Because one memory window of 4K and one window of 2 MB are not 
   sufficient for CardBus controllers in many configurations, Windows XP 
   allocates larger memory windows to CardBus controllers where possible. 
   However, resource windows are static (that is, the operating system 
   does not dynamically allocate larger memory windows if new devices 
   appear.) Under Windows XP, CardBus controllers will be assigned the 
   following resources:

   One 4K memory window, as in Windows 2000

   64 MB memory, if that amount of memory is available. If 64 MB is not 
   available the controller will receive 32 MB; if 32 MB is not available, 
   the controller will receive 16 MB; if 16 MB is not available, the 
   bridge will receive 8 MB; and so on down to a minimum assignment of 1 
   MB in configurations where memory is too constrained for the operating 
   system to provide a larger window.

   Two 256-byte I/O windows"

So I think we have our answer. Windows uses one 4k window, and one 64MB 
window. And they are no more dynamic than we are (we _could_ try to do it 
dynamically, but let's face it, it's fairly painful to dynamically expand 
PCI bus resources - you may need to reprogram everything up to the root, 
so it would be absolutely crazy to do that unless you have some serious 
masochistic tendencies).

So let's just increase our default value to 64M too.

		Linus

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2006-12-21  7:08 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-12-12  8:04 Yenta Cardbus allocation failure Markus Rechberger
2006-12-19  0:12 ` [solved] " Markus Rechberger
2006-12-21  3:40   ` Andrew Morton
2006-12-21  7:07     ` Linus Torvalds

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).