Cardbus/hotplugging is still broken in 2.5.56. Inserting a
card fails due a bogus 'resource conflict', and ejecting it
oopses the kernel. It's been this way since 2.5.4x-something.
Dell Latitude, Texas PCI1131 cardbus bridge, 3c575_cb NIC.
Early boot log:
Linux Kernel Card Services 3.1.22
options: [pci] [cardbus] [pm]
PCI: Found IRQ 11 for device 00:03.0
PCI: Sharing IRQ 11 with 00:03.1
PCI: Sharing IRQ 11 with 00:07.2
PCI: Found IRQ 11 for device 00:03.1
PCI: Sharing IRQ 11 with 00:03.0
PCI: Sharing IRQ 11 with 00:07.2
...
Yenta IRQ list 0618, PCI irq11
Socket status: 30000006
Yenta IRQ list 0618, PCI irq11
Socket status: 30000006
...
cs: IO port probe 0x0c00-0x0cff: clean.
cs: IO port probe 0x0100-0x04ff: excluding 0x210-0x217 0x220-0x22f 0x378-0x37f 0x388-0x38f 0x3c0-0x3df 0x4d0-0x4d7
cs: IO port probe 0x0a00-0x0aff: clean.
So far so good.
Now insert the 3x575_cb NIC:
cs: cb_alloc(bus 5): vendor 0x10b7, device 0x5057
PCI: Device 05:00.0 not available because of resource collisions
Now eject the NIC:
Unable to handle kernel NULL pointer dereference at virtual address 00000004
printing eip:
c019cd1b
*pde = 00000000
Oops: 0002
CPU: 0
EIP: 0060:[<c019cd1b>] Not tainted
EFLAGS: 00010246
EIP is at device_del+0x23/0x74
eax: 00000000 ebx: c7eff44c ecx: c02b2048 edx: 00000000
esi: c7f6d44c edi: c7eff400 ebp: c7ef2000 esp: c7fb7f0c
ds: 007b es: 007b ss: 0068
Process events/0 (pid: 3, threadinfo=c7fb6000 task=c1150c80)
Stack: c7eff44c 00000000 c019cd77 c7eff44c c7eff400 c01970a6 c7eff44c c7eff400
c01e5356 c7eff400 c7ef2000 c7ef2000 c01e72e0 c7feb7e0 c01e277a c7ef2000
c7ef2000 c7ef2000 c7ef200c c7ef2000 00000080 c01e72e0 c7feb7e0 c01e2aa5
Call Trace:
[<c019cd77>] device_unregister+0xb/0x16
[<c01970a6>] pci_remove_device+0xe/0x38
[<c01e5356>] cb_free+0x2a/0x60
[<c01e72e0>] yenta_bh+0x0/0x24
[<c01e277a>] shutdown_socket+0x76/0xe0
[<c01e72e0>] yenta_bh+0x0/0x24
[<c01e2aa5>] do_shutdown+0x5d/0x64
[<c01e2ae6>] parse_events+0x3a/0xd8
[<c01e72fe>] yenta_bh+0x1e/0x24
[<c011fbbd>] worker_thread+0x18d/0x240
[<c011fa30>] worker_thread+0x0/0x240
[<c01e72e0>] yenta_bh+0x0/0x24
[<c01136a4>] default_wake_function+0x0/0x34
[<c01136a4>] default_wake_function+0x0/0x34
[<c0106ddd>] kernel_thread_helper+0x5/0xc
Code: 89 50 04 89 02 89 1b 89 5b 04 ff 05 48 20 2b c0 7e 73 8d 76
Doubleplusuncool.
/Mikael
> Cardbus/hotplugging is still broken in 2.5.56. Inserting a
> card fails due a bogus 'resource conflict', and ejecting it
> oopses the kernel. It's been this way since 2.5.4x-something.
This is a known issue, somebody else reported it to the mailing list
yesterday, and I've put it in my bug db:
http://grabjohn.com/kernelbugdatabase/index.php?action=21&id=18
John.
yOn Sat, 11 Jan 2003, Mikael Pettersson wrote:
> Cardbus/hotplugging is still broken in 2.5.56. Inserting a
> card fails due a bogus 'resource conflict', and ejecting it
> oopses the kernel. It's been this way since 2.5.4x-something.
>
> Dell Latitude, Texas PCI1131 cardbus bridge, 3c575_cb NIC.
I think its a matter of resource collisions only and the oops is
inadequate cleanup on failure. I've tested cardbus/hotplugging on a TI PCI1211 and
Tulip 21142 based NIC. Perhaps find the last working kernel?
Zwane
--
function.linuxpower.ca
On Sat, 11 Jan 2003, Zwane Mwaikambo wrote:
> yOn Sat, 11 Jan 2003, Mikael Pettersson wrote:
>
> > Cardbus/hotplugging is still broken in 2.5.56. Inserting a
> > card fails due a bogus 'resource conflict', and ejecting it
> > oopses the kernel. It's been this way since 2.5.4x-something.
> >
> > Dell Latitude, Texas PCI1131 cardbus bridge, 3c575_cb NIC.
>
> I think its a matter of resource collisions only and the oops is
> inadequate cleanup on failure. I've tested cardbus/hotplugging on a TI PCI1211 and
> Tulip 21142 based NIC. Perhaps find the last working kernel?
I've got the same problem as the one above, with a Realtek rtl8139.
The problem I'm seeing is that
dev->resource[0].start == 0x00000000 and dev->resource[0].end == 0xff
which will not jive with various checks in pcibios_enable_device()
It's still working in 2.4.21-pre3, and the last kernel I was able to boot
succesfully was 2.5.48, although I know for a fact that 2.5.54 already had
the problem.
Hardware on my laptop (Inspiron 8000) is a TI PCI1445 cardbus bridge.
Bas Vermeulen
--
"God, root, what is difference?"
-- Pitr, User Friendly
"God is more forgiving."
-- Dave Aronson
Zwane Mwaikambo writes:
> yOn Sat, 11 Jan 2003, Mikael Pettersson wrote:
>
> > Cardbus/hotplugging is still broken in 2.5.56. Inserting a
> > card fails due a bogus 'resource conflict', and ejecting it
> > oopses the kernel. It's been this way since 2.5.4x-something.
> >
> > Dell Latitude, Texas PCI1131 cardbus bridge, 3c575_cb NIC.
>
> I think its a matter of resource collisions only and the oops is
> inadequate cleanup on failure. I've tested cardbus/hotplugging on a TI PCI1211 and
> Tulip 21142 based NIC. Perhaps find the last working kernel?
I did some tests yesterday, and 2.5.49 was the last kernel to work at all:
boot, insert NIC, and it goes up. But the last few 2.5.4x all seemed to
handle ejection incorrectly: ejecting and reinserting the NIC did _not_
successfully enable it, and manually down/up eth0 didn't help.
/Mikael
The cardbus problems are caused by
[email protected] 2002-11-25 18:31:10-08:00 [email protected]
as far as I can tell.
pci_enable_device() will fail at least on i386 (see
arch/i386/pci/i386.c: pcibios_enable_resource (line 260)) if the
resources have not been assigned previously. Hence the ostensible
resource collisions.
The attached patch should fix the problem.
I have send the patch to Dave Jones some time ago but did not hear from
him yet.
I am not subscribed to the list so please cc me on replys.
Jens
--
Jens Taprogge
Jens Taprogge writes:
> The cardbus problems are caused by
>
> [email protected] 2002-11-25 18:31:10-08:00 [email protected]
>
> as far as I can tell.
>
> pci_enable_device() will fail at least on i386 (see
> arch/i386/pci/i386.c: pcibios_enable_resource (line 260)) if the
> resources have not been assigned previously. Hence the ostensible
> resource collisions.
>
> The attached patch should fix the problem.
>
> I have send the patch to Dave Jones some time ago but did not hear from
> him yet.
>
> I am not subscribed to the list so please cc me on replys.
Thanks. Your patch fixed the cardbus hotplug issue perfectly on my laptop.
It survives multiple insert/eject cycles without any problems.
The patch posted by Yaacov Akiba Slama today also fixed cardbus hotplug
for me, but with his patch the kernel still prints "PCI: No IRQ known for
interrupt pin A of device xx:xx.x. Please try using pci=biosirq" when the
cardbus NIC is inserted; Jens Taprogge's patch silenced that warning.
/Mikael
--- drivers/pcmcia/cardbus.c.original 2003-01-14 19:38:49.000000000 +0200
+++ drivers/pcmcia/cardbus.c 2003-01-15 18:21:40.000000000 +0200
@@ -285,25 +285,29 @@
dev->dev.dma_mask = &dev->dma_mask;
pci_setup_device(dev);
- if (pci_enable_device(dev))
- continue;
strcpy(dev->dev.bus_id, dev->slot_name);
- /* FIXME: Do we need to enable the expansion ROM? */
+ /* We need to assign resources for expansion ROM. */
for (r = 0; r < 7; r++) {
struct resource *res = dev->resource + r;
- if (res->flags)
+ if (!res->start && res->end)
pci_assign_resource(dev, r);
}
/* Does this function have an interrupt at all? */
pci_readb(dev, PCI_INTERRUPT_PIN, &irq_pin);
- if (irq_pin) {
+ if (irq_pin)
dev->irq = irq;
- pci_writeb(dev, PCI_INTERRUPT_LINE, irq);
- }
+
+ /* pci_enable_device needs to be called after pci_assign_resource */
+ /* because it returns an error if (!res->start && res->end). */
+ if (pci_enable_device(dev))
+ continue;
+ if (irq_pin)
+ pci_writeb(dev, PCI_INTERRUPT_LINE, irq);
+
device_register(&dev->dev);
pci_insert_device(dev, bus);
}
You are not freeing the possibly already allocated resources in case of
a failure of either pci_assign_resource() or pca_enable_device(). In
fact you are not even checking if pci_assign_resource() fails. That
seems wrong to me.
Btw.: who is in charge of this file? Dave Jones? Is someone working on
integrating it with PCI Hotplug?
Best Regards
Jens
On Wed, Jan 15, 2003 at 06:26:36PM +0200, Yaacov Akiba Slama wrote:
> Can you test the enclosed patch. It seems to be both simple and to
> resolve the resource collisions and the "No IRQ known" problem.
> I added a smal comment (and modified another) so future janitors won't
> move pci_enable above pci_assign_resource again.
> If everyone is ok, I can send it to Linus for inclusion in BK (I have
> the green light of Dave Jones).
>
> Thanks,
> Yaacov Akiba Slama
>
> Mikael Pettersson wrote:
>
> >Jens Taprogge writes:
> >> The cardbus problems are caused by
> >>
> >> [email protected] 2002-11-25 18:31:10-08:00 [email protected]
> >>
> >> as far as I can tell.
> >>
> >> pci_enable_device() will fail at least on i386 (see
> >> arch/i386/pci/i386.c: pcibios_enable_resource (line 260)) if the
> >> resources have not been assigned previously. Hence the ostensible
> >> resource collisions.
> >>
> >> The attached patch should fix the problem.
> >>
> >> I have send the patch to Dave Jones some time ago but did not hear from
> >> him yet.
> >>
> >> I am not subscribed to the list so please cc me on replys.
> >
> >Thanks. Your patch fixed the cardbus hotplug issue perfectly on my laptop.
> >It survives multiple insert/eject cycles without any problems.
> >
> >The patch posted by Yaacov Akiba Slama today also fixed cardbus hotplug
> >for me, but with his patch the kernel still prints "PCI: No IRQ known for
> >interrupt pin A of device xx:xx.x. Please try using pci=biosirq" when the
> >cardbus NIC is inserted; Jens Taprogge's patch silenced that warning.
> >
> >/Mikael
> >
> >
> >
> --- drivers/pcmcia/cardbus.c.original 2003-01-14 19:38:49.000000000 +0200
> +++ drivers/pcmcia/cardbus.c 2003-01-15 18:21:40.000000000 +0200
> @@ -285,25 +285,29 @@
> dev->dev.dma_mask = &dev->dma_mask;
>
> pci_setup_device(dev);
> - if (pci_enable_device(dev))
> - continue;
>
> strcpy(dev->dev.bus_id, dev->slot_name);
>
> - /* FIXME: Do we need to enable the expansion ROM? */
> + /* We need to assign resources for expansion ROM. */
> for (r = 0; r < 7; r++) {
> struct resource *res = dev->resource + r;
> - if (res->flags)
> + if (!res->start && res->end)
> pci_assign_resource(dev, r);
> }
>
> /* Does this function have an interrupt at all? */
> pci_readb(dev, PCI_INTERRUPT_PIN, &irq_pin);
> - if (irq_pin) {
> + if (irq_pin)
> dev->irq = irq;
> - pci_writeb(dev, PCI_INTERRUPT_LINE, irq);
> - }
> +
> + /* pci_enable_device needs to be called after pci_assign_resource */
> + /* because it returns an error if (!res->start && res->end). */
> + if (pci_enable_device(dev))
> + continue;
>
> + if (irq_pin)
> + pci_writeb(dev, PCI_INTERRUPT_LINE, irq);
> +
> device_register(&dev->dev);
> pci_insert_device(dev, bus);
> }
--
Jens Taprogge
Jens Taprogge wrote :
>You are not freeing the possibly already allocated resources in case of
>a failure of either pci_assign_resource() or pca_enable_device(). In
>fact you are not even checking if pci_assign_resource() fails. That
>seems wrong to me.
There are two separate issues :
1) Fix the "ressource collisions" problem (and irq not known).
2) Freeing ressources in case of failure of some functions.
My patch solves the first issue only in order to make cardbus with rom work.
The point 2 is a janitor work.
Thanks,
Yaacov Akiba Slama
On Wed, Jan 15, 2003 at 08:47:38PM +0100, Jens Taprogge wrote:
> You are not freeing the possibly already allocated resources in case of
> a failure of either pci_assign_resource() or pca_enable_device(). In
> fact you are not even checking if pci_assign_resource() fails. That
> seems wrong to me.
>
> Btw.: who is in charge of this file? Dave Jones?
Not me, more likely David Hinds.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
I am not sure if you have seen the patch I posted on l-k. It should fix
both issues.
Jens
On Wed, Jan 15, 2003 at 10:13:39PM +0200, Yaacov Akiba Slama wrote:
> Jens Taprogge wrote :
>
> >You are not freeing the possibly already allocated resources in case of
> >a failure of either pci_assign_resource() or pca_enable_device(). In
> >fact you are not even checking if pci_assign_resource() fails. That
> >seems wrong to me.
>
> There are two separate issues :
> 1) Fix the "ressource collisions" problem (and irq not known).
> 2) Freeing ressources in case of failure of some functions.
>
> My patch solves the first issue only in order to make cardbus with rom work.
> The point 2 is a janitor work.
>
> Thanks,
> Yaacov Akiba Slama
--
Jens Taprogge
[email protected] wrote:
>I am not sure if you have seen the patch I posted on l-k. It should fix
>both issues.
>
I don't know enough about pci/cardbus, but in
arch/i386/pci.c::pcibios_assign_resources, I can see the following :
if (!r->start && r->end)
pci_assign_resource(dev, idx);
without testing the result and without freeing the ressource for all
index if it fails on one index. So I don't know if your tests are necessary.
Beside that, testing (!r->start && r->end) seems to be more in sync
with arch/i386/pci.c than testing r->flags
Thanks,
Yaacov Akiba Slama
>
>Jens
>
>On Wed, Jan 15, 2003 at 10:13:39PM +0200, Yaacov Akiba Slama wrote:
>
>
>>Jens Taprogge wrote :
>>
>>
>>
>>>You are not freeing the possibly already allocated resources in case of
>>>a failure of either pci_assign_resource() or pca_enable_device(). In
>>>fact you are not even checking if pci_assign_resource() fails. That
>>>seems wrong to me.
>>>
>>>
>>There are two separate issues :
>>1) Fix the "ressource collisions" problem (and irq not known).
>>2) Freeing ressources in case of failure of some functions.
>>
>>My patch solves the first issue only in order to make cardbus with rom work.
>>The point 2 is a janitor work.
>>
>>Thanks,
>>Yaacov Akiba Slama
>>
>>
>
>
>