Re: 2.4.0-test9-pre2: pcmcia 3c59x doesn't work
Horst von Brand wrote: > > I've been using a 3com 3CCFE575CT 10/100 Eth cardbus card without any > trouble in 2.2.18pre and 2.4.0-test8 together with pcmcia-cs-3.1.21 (Sep 5 > snapshot). I'm running Red Hat 6.2 on that machine (Toshiba Satellite Pro > 4280 XDVD) with DHCP. pump works, and sets up the interface. But > 2.4.9-test9-pre2 complains that the device isn't there. The module loads. Hi, Horst. Bit confused by this one. The changes in test9-pre2 shouldn't affect the 3CCFE575CT, and mine works OK. Are you sure it's not the PCI resource allocation problem? Have you tried backing out to the 2.5.0-test9-pre1 3c59x.c? Alternatively, try backing out to test9-pre1's drivers/pci/pci.c. Failing that, I'll need logs, ifconfig output, etc. You know the deal :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre2: pcmcia 3c59x doesn't work
Andrew Morton <[EMAIL PROTECTED]> writes: > Horst von Brand wrote: > > > > I've been using a 3com 3CCFE575CT 10/100 Eth cardbus card without any > > trouble in 2.2.18pre and 2.4.0-test8 together with pcmcia-cs-3.1.21 (Sep 5 > > snapshot). I'm running Red Hat 6.2 on that machine (Toshiba Satellite Pro > > 4280 XDVD) with DHCP. pump works, and sets up the interface. But > > 2.4.9-test9-pre2 complains that the device isn't there. The module loads. > > Hi, Horst. > > Bit confused by this one. The changes in test9-pre2 shouldn't affect > the 3CCFE575CT, and mine works OK. Are you sure it's not the PCI > resource allocation problem? > i have the same problem with the same setup. from the logs, it looks like this is due to a PCI resource allocation conflict: Sep 17 15:56:33 prospero cardmgr[6838]: initializing socket 1 Sep 17 15:56:33 prospero cardmgr[6838]: socket 1: 3Com 3CCFE575B/3CXFE575B Fast EtherLink XL Sep 17 15:56:33 prospero kernel: cs: cb_alloc(bus 5): vendor 0x10b7, device 0x5157 Sep 17 15:56:33 prospero kernel: PCI: Failed to allocate resource 0 for PCI device 10b7:5157 Sep 17 15:56:33 prospero kernel: PCI: Failed to allocate resource 1 for PCI device 10b7:5157 Sep 17 15:56:33 prospero kernel: PCI: Failed to allocate resource 2 for PCI device 10b7:5157 Sep 17 15:56:33 prospero kernel: PCI: Failed to allocate resource 6 for PCI device 10b7:5157 Sep 17 15:56:33 prospero kernel: PCI: Device 05:00.0 not available because of resource collisions Sep 17 15:56:33 prospero kernel: eth0: 3Com PCI 3CCFE575BT Cyclone CardBus at 0x0, <3>PCI: Device 05:00.0 not available because of resource collisions Sep 17 15:56:33 prospero kernel: 3c59x: vortex_probe1 fails. Returns -5 after i suspended the laptop and started again i got this: Sep 18 11:36:47 prospero cardmgr[6838]: shutting down socket 1 Sep 18 11:36:47 prospero cardmgr[6838]: executing: 'modprobe -r 3c575_cb' Sep 18 11:36:49 prospero kernel: cs: cb_alloc(bus 5): vendor 0x, device 0x Sep 18 11:36:49 prospero kernel: PCI: device 05:00.0 has unknown header type 7f, ignoring. Sep 18 11:36:49 prospero kernel: PCI: No IRQ known for interrupt pin ? of device 05:00.0. Please try using pci=biosirq. Sep 18 11:36:52 prospero kernel: cs: cb_free(bus 5) Sep 18 11:36:52 prospero cardmgr[6838]: executing: 'modprobe -r cb_enabler' Sep 18 11:36:59 prospero cardmgr[6838]: initializing socket 1 Sep 18 11:36:59 prospero cardmgr[6838]: socket 1: Anonymous Memory Sep 18 11:36:59 prospero cardmgr[6838]: executing: 'modprobe memory_cs' Sep 18 11:36:59 prospero cardmgr[6838]: + modprobe: Can't locate module memory_cs Sep 18 11:36:59 prospero cardmgr[6838]: modprobe exited with status 255 Sep 18 11:36:59 prospero cardmgr[6838]: module /lib/modules/2.4.0-test9/pcmcia/memory_cs.o not available it looks like the pcmcia daemon is really confused (pci=biosirq didn't make any difference in the past). test9-pre1 worked fine (well, i still had to do 'ifconfig eth0 up' by hand). --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre2: pcmcia 3c59x doesn't work
On 18 Sep 2000, Alex Romosan wrote: I get the same thing with a Xircon realport 10/100/modem card. Works great in test9-pre1 and test8. -dwild > i have the same problem with the same setup. from the logs, it looks > like this is due to a PCI resource allocation conflict: > > Sep 17 15:56:33 prospero cardmgr[6838]: initializing socket 1 > Sep 17 15:56:33 prospero cardmgr[6838]: socket 1: 3Com 3CCFE575B/3CXFE575B Fast >EtherLink XL > Sep 17 15:56:33 prospero kernel: cs: cb_alloc(bus 5): vendor 0x10b7, device 0x5157 > Sep 17 15:56:33 prospero kernel: PCI: Failed to allocate resource 0 for PCI device >10b7:5157 > Sep 17 15:56:33 prospero kernel: PCI: Failed to allocate resource 1 for PCI device >10b7:5157 > Sep 17 15:56:33 prospero kernel: PCI: Failed to allocate resource 2 for PCI device >10b7:5157 > Sep 17 15:56:33 prospero kernel: PCI: Failed to allocate resource 6 for PCI device >10b7:5157 > Sep 17 15:56:33 prospero kernel: PCI: Device 05:00.0 not available because of >resource collisions > Sep 17 15:56:33 prospero kernel: eth0: 3Com PCI 3CCFE575BT Cyclone CardBus at 0x0, ><3>PCI: Device 05:00.0 not available because of resource collisions > Sep 17 15:56:33 prospero kernel: 3c59x: vortex_probe1 fails. Returns -5 > > after i suspended the laptop and started again i got this: > > Sep 18 11:36:47 prospero cardmgr[6838]: shutting down socket 1 > Sep 18 11:36:47 prospero cardmgr[6838]: executing: 'modprobe -r 3c575_cb' > Sep 18 11:36:49 prospero kernel: cs: cb_alloc(bus 5): vendor 0x, device 0x > Sep 18 11:36:49 prospero kernel: PCI: device 05:00.0 has unknown header type 7f, >ignoring. > Sep 18 11:36:49 prospero kernel: PCI: No IRQ known for interrupt pin ? of device >05:00.0. Please try using pci=biosirq. > Sep 18 11:36:52 prospero kernel: cs: cb_free(bus 5) > Sep 18 11:36:52 prospero cardmgr[6838]: executing: 'modprobe -r cb_enabler' > Sep 18 11:36:59 prospero cardmgr[6838]: initializing socket 1 > Sep 18 11:36:59 prospero cardmgr[6838]: socket 1: Anonymous Memory > Sep 18 11:36:59 prospero cardmgr[6838]: executing: 'modprobe memory_cs' > Sep 18 11:36:59 prospero cardmgr[6838]: + modprobe: Can't locate module memory_cs > Sep 18 11:36:59 prospero cardmgr[6838]: modprobe exited with status 255 > Sep 18 11:36:59 prospero cardmgr[6838]: module >/lib/modules/2.4.0-test9/pcmcia/memory_cs.o not available > > it looks like the pcmcia daemon is really confused (pci=biosirq didn't > make any difference in the past). test9-pre1 worked fine (well, i > still had to do 'ifconfig eth0 up' by hand). > > --alex-- > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre2: pcmcia 3c59x doesn't work
On Mon, 18 Sep 2000, Derek Wildstar wrote:
> On 18 Sep 2000, Alex Romosan wrote:
>
> I get the same thing with a Xircon realport 10/100/modem card. Works
> great in test9-pre1 and test8.
>
> -dwild
>
did you try this patch?
--- linux/drivers/pci/pci.c Mon Sep 18 12:35:11 2000
+++ work/drivers/pci/pci.c Mon Sep 18 13:12:20 2000
@@ -714,7 +714,7 @@
* We need to blast all three values with a single write.
*/
pci_write_config_dword(dev, PCI_PRIMARY_BUS, buses);
- if (!is_cardbus) {
+ if (is_cardbus) {
/* Now we can scan all subordinate buses... */
max = pci_do_scan_bus(child);
} else {
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre2: pcmcia 3c59x doesn't work
lest people start shouting at me...
The philosphy behind this patch is:
There are two ways to turn a "guess" into a "fix":
a) to understand why it works
or
b) to make sure it fixes the problem for everyone on the planet and
doesn't break anything...
This time b) seemed easier :)
Regards,
Tigran
On Mon, 18 Sep 2000, Tigran Aivazian wrote:
> On Mon, 18 Sep 2000, Derek Wildstar wrote:
>
> > On 18 Sep 2000, Alex Romosan wrote:
> >
> > I get the same thing with a Xircon realport 10/100/modem card. Works
> > great in test9-pre1 and test8.
> >
> > -dwild
> >
>
> did you try this patch?
>
> --- linux/drivers/pci/pci.c Mon Sep 18 12:35:11 2000
> +++ work/drivers/pci/pci.cMon Sep 18 13:12:20 2000
> @@ -714,7 +714,7 @@
>* We need to blast all three values with a single write.
>*/
> pci_write_config_dword(dev, PCI_PRIMARY_BUS, buses);
> - if (!is_cardbus) {
> + if (is_cardbus) {
> /* Now we can scan all subordinate buses... */
> max = pci_do_scan_bus(child);
> } else {
>
>
> Regards,
> Tigran
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre2: pcmcia 3c59x doesn't work
Andrew Morton <[EMAIL PROTECTED]> said: > Horst von Brand wrote: > > I've been using a 3com 3CCFE575CT 10/100 Eth cardbus card without any > > trouble in 2.2.18pre and 2.4.0-test8 together with pcmcia-cs-3.1.21 (Sep 5 > > snapshot). I'm running Red Hat 6.2 on that machine (Toshiba Satellite Pro > > 4280 XDVD) with DHCP. pump works, and sets up the interface. But > > 2.4.9-test9-pre2 complains that the device isn't there. The module loads. > Bit confused by this one. The changes in test9-pre2 shouldn't affect > the 3CCFE575CT, and mine works OK. Are you sure it's not the PCI > resource allocation problem? Yep, that is it. With and without Tigran's "!cardbus" --> "cardbus" patch I get: Linux PCMCIA Card Services 3.1.20 options: [pci] [cardbus] [pm] Yenta IRQ list 04b0, PCI irq11 Socket status: 3007 Yenta IRQ list 04b0, PCI irq11 Socket status: 3020 cs: cb_alloc(bus 20): vendor 0x10b7, device 0x5257 PCI: Failed to allocate resource 0 for PCI device 10b7:5257 PCI: Failed to allocate resource 1 for PCI device 10b7:5257 PCI: Failed to allocate resource 2 for PCI device 10b7:5257 PCI: Failed to allocate resource 6 for PCI device 10b7:5257 PCI: Device 14:00.0 not available because of resource collisions I understand this means it can't set up the bridge? -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre2: pcmcia 3c59x doesn't work
Tigran Aivazian <[EMAIL PROTECTED]> said:
[...]
> did you try this patch?
>
> --- linux/drivers/pci/pci.c Mon Sep 18 12:35:11 2000
> +++ work/drivers/pci/pci.cMon Sep 18 13:12:20 2000
> @@ -714,7 +714,7 @@
>* We need to blast all three values with a single write.
>*/
> pci_write_config_dword(dev, PCI_PRIMARY_BUS, buses);
> - if (!is_cardbus) {
> + if (is_cardbus) {
> /* Now we can scan all subordinate buses... */
> max = pci_do_scan_bus(child);
> } else {
No changes, same:
Linux PCMCIA Card Services 3.1.20
options: [pci] [cardbus] [pm]
Yenta IRQ list 04b0, PCI irq11
Socket status: 3007
Yenta IRQ list 04b0, PCI irq11
Socket status: 3020
cs: cb_alloc(bus 20): vendor 0x10b7, device 0x5257
PCI: Failed to allocate resource 0 for PCI device 10b7:5257
PCI: Failed to allocate resource 1 for PCI device 10b7:5257
PCI: Failed to allocate resource 2 for PCI device 10b7:5257
PCI: Failed to allocate resource 6 for PCI device 10b7:5257
PCI: Device 14:00.0 not available because of resource collisions
--
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile +56 32 672616
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre2: pcmcia 3c59x doesn't work
Tigran Aivazian wrote:
>
> On Mon, 18 Sep 2000, Derek Wildstar wrote:
>
> > On 18 Sep 2000, Alex Romosan wrote:
> >
> > I get the same thing with a Xircon realport 10/100/modem card. Works
> > great in test9-pre1 and test8.
> >
> > -dwild
> >
>
> did you try this patch?
>
> --- linux/drivers/pci/pci.c Mon Sep 18 12:35:11 2000
> +++ work/drivers/pci/pci.c Mon Sep 18 13:12:20 2000
> @@ -714,7 +714,7 @@
> * We need to blast all three values with a single write.
> */
> pci_write_config_dword(dev, PCI_PRIMARY_BUS, buses);
> - if (!is_cardbus) {
> + if (is_cardbus) {
> /* Now we can scan all subordinate buses... */
> max = pci_do_scan_bus(child);
> } else {
>
I did.
Didn't work for me.
My Xircom is still being detected. But PCI resource allocation still fails.
I'll be happy to set up a remote debug session for anyone interested...
Dag B
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre2: pcmcia 3c59x doesn't work
On Mon, 18 Sep 2000, Horst von Brand wrote:
> Tigran Aivazian <[EMAIL PROTECTED]> said:
>
> [...]
>
> > did you try this patch?
> >
> > --- linux/drivers/pci/pci.c Mon Sep 18 12:35:11 2000
> > +++ work/drivers/pci/pci.c Mon Sep 18 13:12:20 2000
> > @@ -714,7 +714,7 @@
> > * We need to blast all three values with a single write.
> > */
> > pci_write_config_dword(dev, PCI_PRIMARY_BUS, buses);
> > - if (!is_cardbus) {
> > + if (is_cardbus) {
> > /* Now we can scan all subordinate buses... */
> > max = pci_do_scan_bus(child);
> > } else {
>
> No changes, same:
ok, my "plan b)" didn't work for you, then :) we'll have to actually
_understand_ what's going on then...
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre2: pcmcia 3c59x doesn't work
In article <[EMAIL PROTECTED]>, Dag Bakke <[EMAIL PROTECTED]> wrote:
>Tigran Aivazian wrote:
>>
>> On Mon, 18 Sep 2000, Derek Wildstar wrote:
>>
>> > On 18 Sep 2000, Alex Romosan wrote:
>> >
>> > I get the same thing with a Xircon realport 10/100/modem card. Works
>> > great in test9-pre1 and test8.
>> >
>> > -dwild
>> >
>>
>> did you try this patch?
>>
>> --- linux/drivers/pci/pci.c Mon Sep 18 12:35:11 2000
>> +++ work/drivers/pci/pci.c Mon Sep 18 13:12:20 2000
>> @@ -714,7 +714,7 @@
>> * We need to blast all three values with a single write.
>> */
>> pci_write_config_dword(dev, PCI_PRIMARY_BUS, buses);
>> - if (!is_cardbus) {
>> + if (is_cardbus) {
>> /* Now we can scan all subordinate buses... */
>> max = pci_do_scan_bus(child);
>> } else {
>>
>
>
>I did.
>Didn't work for me.
>My Xircom is still being detected. But PCI resource allocation still fails.
>I'll be happy to set up a remote debug session for anyone interested...
There seem to be two potential problems with the new code. How about
this instead:
First off, it's doing the subordinate bus write with a byte write, which
is, as far as I can tell, not legal. When you update the bus
information, you have to update it all at the same time.
Does it help if you change drivers/pci/pci.c pci_scan_bridge(), the line
that says
pci_write_config_byte(dev, PCI_SUBORDINATE_BUS, max);
and you replace that with
buses = (buses & 0xff00) | ((unsigned int)(child->subordinate) << 16);
pci_write_config_dword(dev, PCI_PRIMARY_BUS, buses);
instead.
Second, if the cardbus bridge is already allocated by the BIOS, the "max
bus" logic looks bogus. It looks like
if (!is_cardbus) {
unsigned int cmax = pci_do_scan_bus(child);
if (cmax > max) max = cmax;
}
and it _should_ probably have something like
if (!is_cardbus) {
.. same logic ..
} else {
unsigned int cmax = child->subordinate + 3;
if (cmax > max) max = cmax;
}
because otherwise we'd completely ignore the cardbus "max" values as far
as I can tell, and if the machine has another bus it might be given the
same bus value as the already-configured cardbus bridge.
Do the above two fixes help? If not, I suspect that we're better off
just reverting the new PCI bus allocation until it's fixed.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre2: pcmcia 3c59x doesn't work
On Tue, 19 Sep 2000, Tigran Aivazian wrote:
> On Mon, 18 Sep 2000, Horst von Brand wrote:
>
> > Tigran Aivazian <[EMAIL PROTECTED]> said:
> >
> > [...]
> >
> > > did you try this patch?
> > >
> > > --- linux/drivers/pci/pci.c Mon Sep 18 12:35:11 2000
> > > +++ work/drivers/pci/pci.cMon Sep 18 13:12:20 2000
> > > @@ -714,7 +714,7 @@
> > >* We need to blast all three values with a single write.
> > >*/
> > > pci_write_config_dword(dev, PCI_PRIMARY_BUS, buses);
> > > - if (!is_cardbus) {
> > > + if (is_cardbus) {
> > > /* Now we can scan all subordinate buses... */
> > > max = pci_do_scan_bus(child);
> > > } else {
> >
> > No changes, same:
>
> ok, my "plan b)" didn't work for you, then :) we'll have to actually
> _understand_ what's going on then...
Your "plan b" worked for me...on test9-pre4 my Xircom is working with that
patch, and gets the same old "pci allocation" error without.
-dwild
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre2: pcmcia 3c59x doesn't work
Hi Linus, On Tue, 19 Sep 2000, Linus Torvalds wrote: > Do the above two fixes help? If not, I suspect that we're better off > just reverting the new PCI bus allocation until it's fixed. No, unfortunately they don't help at all, neither individually nor in pair. So far, the only working case was replacing !is_cardbus ->is_cardbus but, of course, this is not a fix because I don't understand it. :( I understand that simply treating cardbus bridges as PCI-PCI bridges does not work (and actually verified it by trying) but can't say more - I know nothing of cardbus bridges (or PCMCIA). It would be a shame to revert back to old ways because we have something working, we just don't understand why or what is the proper way to do it... Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre2: pcmcia 3c59x doesn't work
Linus Torvalds wrote:
In article <[EMAIL PROTECTED]>, Dag Bakke <[EMAIL PROTECTED]> wrote:
>Tigran Aivazian wrote:
>>
>> On Mon, 18 Sep 2000, Derek Wildstar wrote:
>>
>> > On 18 Sep 2000, Alex Romosan wrote:
>> >
>> > I get the same thing with a Xircon realport 10/100/modem card. Works
>> > great in test9-pre1 and test8.
[note: neither of these kernels worked for me]
>> >
>> > -dwild
>> >
>>
>> did you try this patch?
>>
>> --- linux/drivers/pci/pci.c Mon Sep 18 12:35:11 2000
>> +++ work/drivers/pci/pci.c Mon Sep 18 13:12:20 2000
[snip]
> >I did.
> >Didn't work for me.
> >My Xircom is still being detected. But PCI resource allocation still fails.
> >I'll be happy to set up a remote debug session for anyone interested...
>
> There seem to be two potential problems with the new code. How about
> this instead:
>
> First off, it's doing the subordinate bus write with a byte write, which
> is, as far as I can tell, not legal. When you update the bus
> information, you have to update it all at the same time.
>
> Does it help if you change drivers/pci/pci.c pci_scan_bridge(), the line
> that says
>
> pci_write_config_byte(dev, PCI_SUBORDINATE_BUS, max);
>
> and you replace that with
>
> buses = (buses & 0xff00) | ((unsigned int)(child->subordinate) << 16);
> pci_write_config_dword(dev, PCI_PRIMARY_BUS, buses);
>
> instead.
>
> Second, if the cardbus bridge is already allocated by the BIOS, the "max
> bus" logic looks bogus. It looks like
>
> if (!is_cardbus) {
> unsigned int cmax = pci_do_scan_bus(child);
> if (cmax > max) max = cmax;
> }
>
> and it _should_ probably have something like
>
> if (!is_cardbus) {
> .. same logic ..
> } else {
> unsigned int cmax = child->subordinate + 3;
> if (cmax > max) max = cmax;
> }
>
> because otherwise we'd completely ignore the cardbus "max" values as far
> as I can tell, and if the machine has another bus it might be given the
> same bus value as the already-configured cardbus bridge.
>
> Do the above two fixes help? If not, I suspect that we're better off
> just reverting the new PCI bus allocation until it's fixed.
>
> Linus
Nah. Didn't help:
Yenta IRQ list 0698, PCI irq11
Socket status: 3006
Yenta IRQ list 0698, PCI irq11
Socket status: 3020
cs: cb_alloc(bus 6): vendor 0x115d, device 0x0003
PCI: Failed to allocate resource 0 for PCI device 115d:0003
PCI: Failed to allocate resource 1 for PCI device 115d:0003
PCI: Failed to allocate resource 2 for PCI device 115d:0003
PCI: Failed to allocate resource 6 for PCI device 115d:0003
PCI: Device 06:00.0 not available because of resource collisions
PCI: Failed to allocate resource 0 for PCI device 115d:0103
PCI: Failed to allocate resource 1 for PCI device 115d:0103
PCI: Failed to allocate resource 2 for PCI device 115d:0103
PCI: Failed to allocate resource 6 for PCI device 115d:0103
PCI: Device 06:00.1 not available because of resource collisions
With Tigran's fix, resource 0 is successfully allocated, and the message
is approximately:
Found 04:00 [115d/0003] 000200 00
PCI: Failed to allocate resource 1 for PCI device 115d:0003
PCI: Failed to allocate resource 2 for PCI device 115d:0003
PCI: Failed to allocate resource 6 for PCI device 115d:0003
PCI: Enabling device 04:00.0 ( -> 0003)
Found 04:01 [115d/0103] 000300 00
PCI: Failed to allocate resource 1 for PCI device 115d:0103
PCI: Failed to allocate resource 2 for PCI device 115d:0103
PCI: Failed to allocate resource 6 for PCI device 115d:0103
PCI: Enabling device 04:00.1 ( -> 0003)
But loading the driver reveals hw-addr == 0:0:0:0:0:0, and ifconfig'ing
the interface causes a hang.
If I parse the message from Martin Mares
(http://www.cs.helsinki.fi/linux/linux-kernel/2000-38/0532.html)
correctly, a fix is possibly needed in
./drivers/pcmcia/yenta.c , and not in ./drivers/pci/pci.c ?
I tried to grok it, but I never got very much beyond 'Hello World\n'
I notice that most devices in this laptop get IRQ 11. Is this an
indication of anything?
dagblap:~# lspci -v | grep -i irq
Flags: bus master, medium devsel, latency 168, IRQ 11
Flags: bus master, medium devsel, latency 168, IRQ 11
Flags: bus master, medium devsel, latency 32, IRQ 11
Flags: bus master, medium devsel, latency 32, IRQ 11
Flags: bus master, medium devsel, latency 32, IRQ 11
Flags: medium devsel, IRQ 5
Flags: medium devsel, IRQ 11
Flags: medium devsel, IRQ 11
dagblap:~# cat /proc/interrupts
CPU0
0: 92925 XT-PIC timer
1: 3 XT-PIC keyboard
2: 0 XT-PIC cascade
11:431 XT-PIC Texas Instruments PCI1225, Texas
Instruments PCI1225 (#2), eth0
12: 0 XT-PIC PS/2 Mouse
13: 0 XT-PIC fpu
14:874 XT-PIC ide0
15: 3 XT-PIC ide1
NMI: 0
ERR: 0
Dag B
-
To unsubscribe from this list: send the line "unsubscribe linux-ker
Re: 2.4.0-test9-pre2: pcmcia 3c59x doesn't work
[EMAIL PROTECTED] (Linus Torvalds) said: > [...] Just to confirm that 2.4.0-test9-pre5 works fine here. Thanks! -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
