* Re: [solved] Yenta Cardbus allocation failure
@ 2006-12-19 8:55 Chuck Ebbert
2006-12-19 9:24 ` Markus Rechberger
0 siblings, 1 reply; 5+ messages in thread
From: Chuck Ebbert @ 2006-12-19 8:55 UTC (permalink / raw)
To: Markus Rechberger; +Cc: linux-kernel, Dominik Brodowski
In-Reply-To: <d9def9db0612181612v657197ees925609243fc1ef65@mail.gmail.com>
On Tue, 19 Dec 2006 01:12:07 +0100, Markus Rechberger 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
Wow, 3 regions of 16MB each! Your change fixes this problem for you, but
what if someone needs four such regions?
--
MBTI: IXTP
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [solved] Yenta Cardbus allocation failure
2006-12-19 8:55 [solved] Yenta Cardbus allocation failure Chuck Ebbert
@ 2006-12-19 9:24 ` Markus Rechberger
0 siblings, 0 replies; 5+ messages in thread
From: Markus Rechberger @ 2006-12-19 9:24 UTC (permalink / raw)
To: Chuck Ebbert; +Cc: linux-kernel, Dominik Brodowski
On 12/19/06, Chuck Ebbert <76306.1226@compuserve.com> wrote:
> In-Reply-To: <d9def9db0612181612v657197ees925609243fc1ef65@mail.gmail.com>
>
> On Tue, 19 Dec 2006 01:12:07 +0100, Markus Rechberger 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
>
> Wow, 3 regions of 16MB each! Your change fixes this problem for you, but
> what if someone needs four such regions?
>
I documented everything I found about that issue (even the allocated
resources in window$)
http://linuxtv.org/v4lwiki/index.php/Talk:Pinnacle/310c#PCI_allocation_failed
that's why I wrote that the current implementation isn't nice..
I'm currently on the cx88 driver (which needs that memory region) to
get my Pinnacle Cardbus device work..
I won't get back to the PCI subsystem before I'm done with it.
Markus
^ permalink raw reply [flat|nested] 5+ messages in thread
* Yenta Cardbus allocation failure
@ 2006-12-12 8:04 Markus Rechberger
2006-12-19 0:12 ` [solved] " Markus Rechberger
0 siblings, 1 reply; 5+ 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] 5+ messages in thread* Re: [solved] Yenta Cardbus allocation failure
2006-12-12 8:04 Markus Rechberger
@ 2006-12-19 0:12 ` Markus Rechberger
2006-12-21 3:40 ` Andrew Morton
0 siblings, 1 reply; 5+ 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] 5+ 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; 5+ 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] 5+ 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; 5+ 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] 5+ messages in thread
end of thread, other threads:[~2006-12-21 7:08 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-12-19 8:55 [solved] Yenta Cardbus allocation failure Chuck Ebbert
2006-12-19 9:24 ` Markus Rechberger
-- strict thread matches above, loose matches on Subject: below --
2006-12-12 8:04 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
all inboxes | Powered by JetHome®