As per subject - my RBEM56G-100BTX isn't usable due to the reasons
printed in /var/log/messages. This has already been reported but
I don't recall seeing patches or any debug stuff to be tried
[...]
NET4: Linux TCP/IP 1.0 for NET4.0
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 32768)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
cs: cb_alloc(bus 2): vendor 0x115d, device 0x0003
PCI: Device 02:00.0 not available because of resource collisions
PCI: Device 02:00.1 not available because of resource collisions
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
[...]
--alessandro
"Seems that you can't get any more than half free"
(Bruce Springsteen, "Straight Time")
> PCI: Device 02:00.0 not available because of resource collisions
> PCI: Device 02:00.1 not available because of resource collisions
Been there. Done that. Does the attached patch help? It did for me.
/Valdis
On Thu, Dec 12, 2002 at 05:47:17PM -0500, [email protected] wrote:
> > PCI: Device 02:00.0 not available because of resource collisions
> > PCI: Device 02:00.1 not available because of resource collisions
>
> Been there. Done that. Does the attached patch help? It did for me.
Fixes the problem for me :)
thanks for the patch,
greg k-h
On Thu, 12 Dec 2002 16:43:30 PST, Greg KH said:
> On Thu, Dec 12, 2002 at 05:47:17PM -0500, [email protected] wrote:
> > > PCI: Device 02:00.0 not available because of resource collisions
> > > PCI: Device 02:00.1 not available because of resource collisions
> >
> > Been there. Done that. Does the attached patch help? It did for me.
>
> Fixes the problem for me :)
Glad to hear it. I'm pretty sure I merely backed out a broken change, but
two decades have left me for a healthy respect for "Mel the Real Programmer"
stories ;)
/Valdis
On Thu, 2002-12-12 at 23:47, [email protected] wrote:
> Been there. Done that. Does the attached patch help? It did for me.
>
> /Valdis
>
>
> ----
>
> --- drivers/pcmcia/cardbus.c.dist 2002-12-03 01:49:29.000000000 -0500
> +++ drivers/pcmcia/cardbus.c 2002-12-03 01:50:23.000000000 -0500
> @@ -283,8 +283,6 @@
> dev->hdr_type = hdr & 0x7f;
>
> pci_setup_device(dev);
> - if (pci_enable_device(dev))
> - continue;
>
> strcpy(dev->dev.bus_id, dev->slot_name);
>
> @@ -302,6 +300,8 @@
> pci_writeb(dev, PCI_INTERRUPT_LINE, irq);
> }
>
> + if (pci_enable_device(dev))
> + continue;
> device_register(&dev->dev);
> pci_insert_device(dev, bus);
> }
interesting. BUT aren't we writing to the device 3 lines before where
you add the pci_enable_device()? That sounds like a bad plan to me ;(
On Fri, 13 Dec 2002 11:10:24 +0100, Arjan van de Ven said:
> On Thu, 2002-12-12 at 23:47, [email protected] wrote:
> > --- drivers/pcmcia/cardbus.c.dist 2002-12-03 01:49:29.000000000 -0500
> > +++ drivers/pcmcia/cardbus.c 2002-12-03 01:50:23.000000000 -0500
> > @@ -283,8 +283,6 @@
> > dev->hdr_type = hdr & 0x7f;
> >
> > pci_setup_device(dev);
> > - if (pci_enable_device(dev))
> > - continue;
> >
> > strcpy(dev->dev.bus_id, dev->slot_name);
> >
> > @@ -302,6 +300,8 @@
> > pci_writeb(dev, PCI_INTERRUPT_LINE, irq);
> > }
> >
> > + if (pci_enable_device(dev))
> > + continue;
> > device_register(&dev->dev);
> > pci_insert_device(dev, bus);
> > }
>
> interesting. BUT aren't we writing to the device 3 lines before where
> you add the pci_enable_device()? That sounds like a bad plan to me ;(
That's where pci_enable_device() *USED* to be - this is backing out a change
made in 2.5.50 - it added the if/continue wrapper and moved it up about 15
lines in the code. The problem seems to be that for many devices,
pci_enable_device() fails unless we do the pci_writeb() magic first. Or
perhaps it's the call to pci_assign_resource() - I don't know. ;) The 2.4.18
tree has the pci_enable_device() at the same place - just without the if/
continue around it. It can't be THAT evil, as that's the way 2.4.0 to 2.4.18
and 2.5.0 to 2.5.49 did it.. ;)
I see why the if/continue was added - you don't want to be calling
device_register()/pci_insert_device() if pci_enable_device() loses. I don't
see why 2.5.50 moved the code up after pci_setup_device(). There's an outside
chance that the concept of moving the call was correct, but that it should have
been moved to between the calls to pci_assign_resource() and pci_readb().
If that's the case, then you're correct as well....
/Valdis (who shouldn't be trying to think before caffeine.. ;)
Arjan> interesting. BUT aren't we writing to the device 3 lines before
Arjan> where you add the pci_enable_device()? That sounds like a bad
Arjan> plan to me ;(
Valdis> I see why the if/continue was added - you don't want to be
Valdis> calling device_register()/pci_insert_device() if
Valdis> pci_enable_device() loses. I don't see why 2.5.50 moved the
Valdis> code up after pci_setup_device(). There's an outside chance
Valdis> that the concept of moving the call was correct, but that it
Valdis> should have been moved to between the calls to
Valdis> pci_assign_resource() and pci_readb(). If that's the case,
Valdis> then you're correct as well....
I can confirm that this indeed works. I moved the two lines before
pci_readb and the card works (every character you now read went through
it). Who shall submit a patch to Linus ?
Now I have to figure out, how to make it load without manual modprobe
xircom_cb. Oh the joys of new module loader.
Petr
--
Computers are like air conditioners. Both stop working, if you open
windows.
-- Adam Heath
On Fri, 13 Dec 2002 17:33:00 +0100, Petr Konecny <[email protected]> said:
> Valdis> I see why the if/continue was added - you don't want to be
> Valdis> calling device_register()/pci_insert_device() if
> Valdis> pci_enable_device() loses. I don't see why 2.5.50 moved the
> Valdis> code up after pci_setup_device(). There's an outside chance
> Valdis> that the concept of moving the call was correct, but that it
> Valdis> should have been moved to between the calls to
> Valdis> pci_assign_resource() and pci_readb(). If that's the case,
> Valdis> then you're correct as well....
> I can confirm that this indeed works. I moved the two lines before
> pci_readb and the card works (every character you now read went through
> it). Who shall submit a patch to Linus ?
The problem is this from the 2.5.50 Changelog that Linus posted:
Dave Jones <[email protected]>:
...
o make cardbus PCI enable earlier
I'm willing to submit a patch, but I think Dave has to make the call whether
it should be backed out entirely, or moved after pci_assign_resource().
I certainly don't understand the code *or* PCI well enough to decide between
those two option...
/Valdis
On Fri, Dec 13, 2002 at 12:18:58PM -0500, [email protected] wrote:
> On Fri, 13 Dec 2002 17:33:00 +0100, Petr Konecny <[email protected]> said:
> > > I see why the if/continue was added - you don't want to be
> > > calling device_register()/pci_insert_device() if
> > > pci_enable_device() loses. I don't see why 2.5.50 moved the
> > > code up after pci_setup_device(). There's an outside chance
> > > that the concept of moving the call was correct, but that it
> > > should have been moved to between the calls to
> > > pci_assign_resource() and pci_readb(). If that's the case,
> > > then you're correct as well....
> > I can confirm that this indeed works. I moved the two lines before
> > pci_readb and the card works (every character you now read went through
> > it). Who shall submit a patch to Linus ?
>
> The problem is this from the 2.5.50 Changelog that Linus posted:
>
> Dave Jones <[email protected]>:
> ...
> o make cardbus PCI enable earlier
>
> I'm willing to submit a patch, but I think Dave has to make the call whether
> it should be backed out entirely, or moved after pci_assign_resource().
> I certainly don't understand the code *or* PCI well enough to decide between
> those two option...
It's my understanding that pci_enable_device() *must* be called
before we fiddle with dev->resource, dev->irq and the like.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Fri, 13 Dec 2002 17:36:56 GMT, Dave Jones said:
> It's my understanding that pci_enable_device() *must* be called
> before we fiddle with dev->resource, dev->irq and the like.
OK.. it looks like the problem only hits if it's a PCMCIA card *with an
onboard ROM*.
The immediate problem cause is in pcibios_enable_resources():
if (!r->start && r->end) {
printk(KERN_ERR "PCI: Device %s not available because of resource collisions\n", dev->slot_name);
If there's an onboard ROM, this is set up in pcibios_assign_resources():
if (pci_probe & PCI_ASSIGN_ROMS) {
r = &dev->resource[PCI_ROM_RESOURCE];
r->end -= r->start;
r->start = 0;
if (r->end)
pci_assign_resource(dev, PCI_ROM_RESOURCE);
}
but this hasn't happened yet in cb_alloc():
/* FIXME: Do we need to enable the expansion ROM? */
for (r = 0; r < 7; r++) {
struct resource *res = dev->resource + r;
if (res->flags)
pci_assign_resource(dev, r);
}
So I think right *AFTER* this code is the right place for pci_enable_device()
because otherwise we won't have allocated the ROMs, so we'll get conflicts.
/Valdis (who went nuts looking at <6 and <7 all over the place. Should I
volunteer to clean these up to #defines rather than inline magic numbers? ;)
Dave Jones wrote:
> It's my understanding that pci_enable_device() *must* be called
> before we fiddle with dev->resource, dev->irq and the like.
True and correct, but -- this particular case is inside the cardbus
core, where it presumeably might have a better idea of when it is best
to call pci_enable_device (or perhaps even not at all, and twiddle the
bits itself).
On Fri, 13 Dec 2002 [email protected] wrote:
> On Fri, 13 Dec 2002 17:36:56 GMT, Dave Jones said:
>
> > It's my understanding that pci_enable_device() *must* be called
> > before we fiddle with dev->resource, dev->irq and the like.
>
> OK.. it looks like the problem only hits if it's a PCMCIA card *with an
> onboard ROM*.
Hmm i just saw this thread, which card is the non working one?;
The computer is still running 2.5.50
02:00.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41)
Subsystem: CNet Technology Inc: Unknown device 401a
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, 10000ns max)
Interrupt: pin A routed to IRQ 9
Region 0: I/O ports at 1c00 [size=128]
Region 1: Memory at 10800000 (32-bit, non-prefetchable) [size=1K]
Expansion ROM at 10400000 [size=256K]
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME+
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
# PCMCIA/CardBus support
CONFIG_PCMCIA=y
CONFIG_PCMCIA_XIRCOM=y
# CONFIG_PCMCIA_XIRTULIP is not set
# PCMCIA network device support
CONFIG_NET_PCMCIA=y
# CONFIG_PCMCIA_XIRC2PS is not set
--
function.linuxpower.ca
On Fri, 2002-12-13 at 19:03, Jeff Garzik wrote:
> Dave Jones wrote:
> > It's my understanding that pci_enable_device() *must* be called
> > before we fiddle with dev->resource, dev->irq and the like.
>
>
> True and correct, but -- this particular case is inside the cardbus
> core, where it presumeably might have a better idea of when it is best
> to call pci_enable_device (or perhaps even not at all, and twiddle the
> bits itself).
We can use enable_device_bars() to skip the ROM but do the rest, then
fix the ROM up 8)
> On Fri, 13 Dec 2002 [email protected] wrote:
> > On Fri, 13 Dec 2002 17:36:56 GMT, Dave Jones said:
> >
> > > It's my understanding that pci_enable_device() *must* be called
> > > before we fiddle with dev->resource, dev->irq and the like.
> >
> > OK.. it looks like the problem only hits if it's a PCMCIA card *with an
> > onboard ROM*.
> Hmm i just saw this thread, which card is the non working one?;
It's a RBEM56G-100.
Sorry it took me a while to reply - Valdis' patch does fix the problem for
me, too. Awaiting for a final form of the fix in the upcoming series :)
Thanks,
--alessandro
On Sat, 14 Dec 2002 09:28:19 PST, "ALESSANDRO.SUARDI" said:
> > On Fri, 13 Dec 2002 [email protected] wrote:
> > > On Fri, 13 Dec 2002 17:36:56 GMT, Dave Jones said:
> > >
> > > > It's my understanding that pci_enable_device() *must* be called
> > > > before we fiddle with dev->resource, dev->irq and the like.
> > >
> > > OK.. it looks like the problem only hits if it's a PCMCIA card *with an
> > > onboard ROM*.
> > Hmm i just saw this thread, which card is the non working one?;
>
> It's a RBEM56G-100.
>
> Sorry it took me a while to reply - Valdis' patch does fix the problem for
> me, too. Awaiting for a final form of the fix in the upcoming series :)
Same here. I was getting bit on a Xircom card:
03:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03)
03:00.1 Serial controller: Xircom Cardbus Ethernet + 56k Modem (rev 03)
Dave has a point about not poking IRQ's before it's initialized, so I think
I'll let him and Alan discuss the *right* way to fix it. (Though if there's
need to test a patch more elegant/correct than mine, I'm more than happy to
do so...)
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech