Re: [solved] Yenta Cardbus allocation failure
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [solved] Yenta Cardbus allocation failure
On Tue, 19 Dec 2006 01:12:07 +0100 "Markus Rechberger" <[EMAIL PROTECTED]> 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 > ... > 3000-35ff : PCI Bus #02 > 3000-32ff : PCI CardBus #03 > 3600-360003ff : :00:1f.1 > 3900-3bff : PCI CardBus #03 > 3900-39ff : :03:00.0 > 3a00-3aff : :03:00.1 > 3b00-3bff : :03:00.2 <- this one failed to allocate previously > 3c00-3eff : PCI CardBus #07 > 4100-43ff : 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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [solved] Yenta Cardbus allocation failure
On Tue, 19 Dec 2006 01:12:07 +0100 Markus Rechberger [EMAIL PROTECTED] 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 ... 3000-35ff : PCI Bus #02 3000-32ff : PCI CardBus #03 3600-360003ff : :00:1f.1 3900-3bff : PCI CardBus #03 3900-39ff : :03:00.0 3a00-3aff : :03:00.1 3b00-3bff : :03:00.2 - this one failed to allocate previously 3c00-3eff : PCI CardBus #07 4100-43ff : 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? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [solved] Yenta Cardbus allocation failure
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [solved] Yenta Cardbus allocation failure
On 12/19/06, Chuck Ebbert <[EMAIL PROTECTED]> wrote: In-Reply-To: <[EMAIL PROTECTED]> 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 > ... > 3000-35ff : PCI Bus #02 > 3000-32ff : PCI CardBus #03 > 3600-360003ff : :00:1f.1 > 3900-3bff : PCI CardBus #03 > 3900-39ff : :03:00.0 > 3a00-3aff : :03:00.1 > 3b00-3bff : :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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [solved] Yenta Cardbus allocation failure
In-Reply-To: <[EMAIL PROTECTED]> 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 > ... > 3000-35ff : PCI Bus #02 > 3000-32ff : PCI CardBus #03 > 3600-360003ff : :00:1f.1 > 3900-3bff : PCI CardBus #03 > 3900-39ff : :03:00.0 > 3a00-3aff : :03:00.1 > 3b00-3bff : :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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [solved] Yenta Cardbus allocation failure
In-Reply-To: [EMAIL PROTECTED] 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 ... 3000-35ff : PCI Bus #02 3000-32ff : PCI CardBus #03 3600-360003ff : :00:1f.1 3900-3bff : PCI CardBus #03 3900-39ff : :03:00.0 3a00-3aff : :03:00.1 3b00-3bff : :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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [solved] Yenta Cardbus allocation failure
On 12/19/06, Chuck Ebbert [EMAIL PROTECTED] wrote: In-Reply-To: [EMAIL PROTECTED] 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 ... 3000-35ff : PCI Bus #02 3000-32ff : PCI CardBus #03 3600-360003ff : :00:1f.1 3900-3bff : PCI CardBus #03 3900-39ff : :03:00.0 3a00-3aff : :03:00.1 3b00-3bff : :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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [solved] Yenta Cardbus allocation failure
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 ... 3000-35ff : PCI Bus #02 3000-32ff : PCI CardBus #03 3600-360003ff : :00:1f.1 3900-3bff : PCI CardBus #03 3900-39ff : :03:00.0 3a00-3aff : :03:00.1 3b00-3bff : :03:00.2 <- this one failed to allocate previously 3c00-3eff : PCI CardBus #07 4100-43ff : 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- SERR- Interrupt: pin A routed to IRQ 10 Region 0: Memory at 3900 (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- SERR- Interrupt: pin A routed to IRQ 10 Region 0: Memory at 3a00 (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- SERR- Interrupt: pin A routed to IRQ 10 NEW --> Region 0: Memory at 3b00 (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 <[EMAIL PROTECTED]> 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: :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- SERR- TAbort- SERR- TAbort- SERR- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [solved] Yenta Cardbus allocation failure
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 ... 3000-35ff : PCI Bus #02 3000-32ff : PCI CardBus #03 3600-360003ff : :00:1f.1 3900-3bff : PCI CardBus #03 3900-39ff : :03:00.0 3a00-3aff : :03:00.1 3b00-3bff : :03:00.2 - this one failed to allocate previously 3c00-3eff : PCI CardBus #07 4100-43ff : 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 3900 (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 3a00 (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 3b00 (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 [EMAIL PROTECTED] 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: :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 3600 (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- :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 3700 (32-bit, non-prefetchable) [size=16M] Capabilities: [4c] Power Management version 2
