* Re: Problems with PCMCIA (Texas Instruments PCI1410)
@ 2003-08-26 22:56 Daniel Ritz
2003-08-27 12:59 ` Russell King
2003-08-27 23:04 ` Problems with PCMCIA (Texas Instruments PCI1410) Sven Dowideit
0 siblings, 2 replies; 12+ messages in thread
From: Daniel Ritz @ 2003-08-26 22:56 UTC (permalink / raw)
To: Tom Marshall; +Cc: linux-kernel
can you please retest with -test4 and russell's yenta patches?
http://patches.arm.linux.org.uk/pcmcia/yenta-20030817.tar
if that doesn't work out: could you please add these lines to in yenta_socket.c?
in yenta_events(), before return:
printk("yenta_events: socket %p, cb: %x, csc: %x\n", socket, cb_event, csc);
in yenta_get_status(), before return:
printk("yenta_get_status: socket %p, state: %x\n", socket, state);
and then report the output on boot, when removig, inserting, cardctl eject, cardctl insert?
this could give an idea what's going on....
rgds
-daniel
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: Problems with PCMCIA (Texas Instruments PCI1410) 2003-08-26 22:56 Problems with PCMCIA (Texas Instruments PCI1410) Daniel Ritz @ 2003-08-27 12:59 ` Russell King 2003-09-05 21:53 ` Problems with PCMCIA (Texas Instruments PCI1450) Sven Dowideit 2003-08-27 23:04 ` Problems with PCMCIA (Texas Instruments PCI1410) Sven Dowideit 1 sibling, 1 reply; 12+ messages in thread From: Russell King @ 2003-08-27 12:59 UTC (permalink / raw) To: Daniel Ritz; +Cc: Tom Marshall, linux-kernel On Wed, Aug 27, 2003 at 12:56:33AM +0200, Daniel Ritz wrote: > can you please retest with -test4 and russell's yenta patches? > http://patches.arm.linux.org.uk/pcmcia/yenta-20030817.tar I've just created http://pcmcia.arm.linux.org.uk/ to document the currently known problems and to contain patches for them. > if that doesn't work out: could you please add these lines to in > yenta_socket.c? What seems to happen is that some peoples cardbus bridges don't report the "card insert" interrupt, or they do and the socket status does not report that the card is inserted. I'll review all the reports thus far this afternoon and expand the problem description on the website. -- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problems with PCMCIA (Texas Instruments PCI1450) 2003-08-27 12:59 ` Russell King @ 2003-09-05 21:53 ` Sven Dowideit 2003-09-05 17:58 ` Russell King 2003-09-05 18:19 ` Daniel Ritz 0 siblings, 2 replies; 12+ messages in thread From: Sven Dowideit @ 2003-09-05 21:53 UTC (permalink / raw) To: Russell King; +Cc: Daniel Ritz, Tom Marshall, linux-kernel On Wed, 2003-08-27 at 22:59, Russell King wrote: > I've just created http://pcmcia.arm.linux.org.uk/ to document the > currently known problems and to contain patches for them. > ok, I've built and booted linux 2.5.70 to 2.5.75, and it seems that the detecting the aironet card as a memory_cs device happens in 2.5.74 _but_ I did come across a number of other weirdnesses on the way. 1. 2.5.71 was missing a #include <linux/cpu.h> in flow.c 2. when i patched 2.5.70 to 2.5.71 and then 2.5.72 somehow SMP became enabled, and this stopped pcmcia from working at all 3. my /etc/defaults/pcmcia contained the line PCIC-i82365, which seemed not tp cause 2.5.70 any problems, but after that i had to change that to yenta before pcmicia started successfully I assume the next step is to apply the 2.5.74 patch in pieces ? cheers Sven ----------------- from dmesg 2.5.73 Linux Kernel Card Services 3.1.22 options: [pci] [cardbus] [pm] PCI: Found IRQ 9 for device 00:02.0 PCI: Sharing IRQ 9 with 00:05.0 PCI: Sharing IRQ 9 with 01:00.0 Yenta IRQ list 00b8, PCI irq9 Socket status: 30000006 PCI: Found IRQ 9 for device 00:02.1 Yenta IRQ list 00b8, PCI irq9 Socket status: 30000010 cs: IO port probe 0x0c00-0x0cff: clean. cs: IO port probe 0x0800-0x08ff: clean. cs: IO port probe 0x0100-0x04ff: excluding 0x378-0x37f 0x3c0-0x3df 0x4d0-0x4d7 cs: IO port probe 0x0a00-0x0aff: clean. cs: memory probe 0xa0000000-0xa0ffffff: clean. airo: Doing fast bap_reads airo: MAC enabled eth1 0:40:96:33:e:a4 eth1: index 0x05: Vcc 5.0, Vpp 5.0, irq 3, io 0x0100-0x013f bad: scheduling while atomic! Call Trace: [<c0117666>] schedule+0x3b6/0x3c0 [<e0852bea>] sendcommand+0xaa/0xe0 [airo] [<e0852b0c>] issuecommand+0x5c/0x90 [airo] [<e08530ca>] PC4500_accessrid+0x4a/0x90 [airo] [<e0853177>] PC4500_readrid+0x67/0x120 [airo] [<c0175118>] padzero+0x28/0x30 ----------------- dmesg from 2.5.74 Yenta IRQ list 0000, PCI irq9 Socket status: 30000006 PCI: Found IRQ 9 for device 0000:00:02.1 ti113x: Routing card interrupts to PCI Yenta IRQ list 0000, PCI irq9 Socket status: 30000010 cs: IO port probe 0x0c00-0x0cff: clean. cs: IO port probe 0x0800-0x08ff: clean. cs: IO port probe 0x0100-0x04ff: excluding 0x378-0x37f 0x3c0-0x3df 0x4d0-0x4d7 cs: IO port probe 0x0a00-0x0aff: clean. cs: memory probe 0xa0000000-0xa0ffffff: clean. ---------------- the differences between the 2 .config files root@sven:/usr/src/2.5# diff linux-2.5.73/.config linux-2.5.74/.config 174d173 < CONFIG_BINFMT_AOUT=m 175a175 > CONFIG_BINFMT_AOUT=m 178a179,183 > # Generic Driver Options > # > # CONFIG_FW_LOADER is not set > > # 350d354 < # CONFIG_SCSI_NCR53C7xx is not set 352d355 < # CONFIG_SCSI_NCR53C8XX is not set 711d713 < # CONFIG_MOUSE_PS2_SYNAPTICS is not set 747a750 > # CONFIG_I2C_PROSAVAGE is not set 758a762 > # CONFIG_I2C_ALI1535 is not set 774a779 > # CONFIG_SENSORS_LM78 is not set 1266a1272 > # CONFIG_USB_AX8817X is not set ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problems with PCMCIA (Texas Instruments PCI1450) 2003-09-05 21:53 ` Problems with PCMCIA (Texas Instruments PCI1450) Sven Dowideit @ 2003-09-05 17:58 ` Russell King 2003-09-05 18:19 ` Daniel Ritz 1 sibling, 0 replies; 12+ messages in thread From: Russell King @ 2003-09-05 17:58 UTC (permalink / raw) To: Sven Dowideit; +Cc: Daniel Ritz, Tom Marshall, linux-kernel On Sat, Sep 06, 2003 at 07:53:42AM +1000, Sven Dowideit wrote: > On Wed, 2003-08-27 at 22:59, Russell King wrote: > > I've just created http://pcmcia.arm.linux.org.uk/ to document the > > currently known problems and to contain patches for them. > > > ok, I've built and booted linux 2.5.70 to 2.5.75, and it seems that the > detecting the aironet card as a memory_cs device happens in 2.5.74 Ok, there's two sets of changes between .73 and .74 which touch PCMCIA. The first is 2.5.73-bk1-bk2 and the second is 2.5.73-bk8-bk9. ftp.kernel.org:/pub/linux/kernel/v2.5/snapshots/incr/patch-2.5.73-bk1-bk2.bz2 ftp.kernel.org:/pub/linux/kernel/v2.5/snapshots/incr/patch-2.5.73-bk8-bk9.bz2 I'm not going to try to guess which caused the problem, but I'm intrigued to know which is causing the problems. Thanks for your efforts so far tracking the problem down. -- Russell King (rmk@arm.linux.org.uk) http://www.arm.linux.org.uk/personal/ Linux kernel maintainer of: 2.6 ARM Linux - http://www.arm.linux.org.uk/ 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problems with PCMCIA (Texas Instruments PCI1450) 2003-09-05 21:53 ` Problems with PCMCIA (Texas Instruments PCI1450) Sven Dowideit 2003-09-05 17:58 ` Russell King @ 2003-09-05 18:19 ` Daniel Ritz [not found] ` <20030905193811.C14076@flint.arm.linux.org.uk> 1 sibling, 1 reply; 12+ messages in thread From: Daniel Ritz @ 2003-09-05 18:19 UTC (permalink / raw) To: Sven Dowideit, Russell King; +Cc: Tom Marshall, linux-kernel ok, now i can reproduce the problem on my ti1410 too. on boot detection works fine with an UP kernel and fails with an SMP kernel. thanx for the hint. i go to look at the csets a bit and try to find out more.... (i think i know which change...) On Fri September 5 2003 23:53, Sven Dowideit wrote: > On Wed, 2003-08-27 at 22:59, Russell King wrote: > > I've just created http://pcmcia.arm.linux.org.uk/ to document the > > currently known problems and to contain patches for them. > > > ok, I've built and booted linux 2.5.70 to 2.5.75, and it seems that the > detecting the aironet card as a memory_cs device happens in 2.5.74 > > _but_ I did come across a number of other weirdnesses on the way. > 1. 2.5.71 was missing a #include <linux/cpu.h> in flow.c > 2. when i patched 2.5.70 to 2.5.71 and then 2.5.72 somehow SMP became > enabled, and this stopped pcmcia from working at all > 3. my /etc/defaults/pcmcia contained the line PCIC-i82365, which seemed > not tp cause 2.5.70 any problems, but after that i had to change that to > yenta before pcmicia started successfully > > I assume the next step is to apply the 2.5.74 patch in pieces ? > > cheers > Sven > > ----------------- > from dmesg 2.5.73 > > Linux Kernel Card Services 3.1.22 > options: [pci] [cardbus] [pm] > PCI: Found IRQ 9 for device 00:02.0 > PCI: Sharing IRQ 9 with 00:05.0 > PCI: Sharing IRQ 9 with 01:00.0 > Yenta IRQ list 00b8, PCI irq9 > Socket status: 30000006 > PCI: Found IRQ 9 for device 00:02.1 > Yenta IRQ list 00b8, PCI irq9 > Socket status: 30000010 > cs: IO port probe 0x0c00-0x0cff: clean. > cs: IO port probe 0x0800-0x08ff: clean. > cs: IO port probe 0x0100-0x04ff: excluding 0x378-0x37f 0x3c0-0x3df > 0x4d0-0x4d7 > cs: IO port probe 0x0a00-0x0aff: clean. > cs: memory probe 0xa0000000-0xa0ffffff: clean. > airo: Doing fast bap_reads > airo: MAC enabled eth1 0:40:96:33:e:a4 > eth1: index 0x05: Vcc 5.0, Vpp 5.0, irq 3, io 0x0100-0x013f > bad: scheduling while atomic! > Call Trace: > [<c0117666>] schedule+0x3b6/0x3c0 > [<e0852bea>] sendcommand+0xaa/0xe0 [airo] > [<e0852b0c>] issuecommand+0x5c/0x90 [airo] > [<e08530ca>] PC4500_accessrid+0x4a/0x90 [airo] > [<e0853177>] PC4500_readrid+0x67/0x120 [airo] > [<c0175118>] padzero+0x28/0x30 > > ----------------- > dmesg from 2.5.74 > > Yenta IRQ list 0000, PCI irq9 > Socket status: 30000006 > PCI: Found IRQ 9 for device 0000:00:02.1 > ti113x: Routing card interrupts to PCI > Yenta IRQ list 0000, PCI irq9 > Socket status: 30000010 > cs: IO port probe 0x0c00-0x0cff: clean. > cs: IO port probe 0x0800-0x08ff: clean. > cs: IO port probe 0x0100-0x04ff: excluding 0x378-0x37f 0x3c0-0x3df > 0x4d0-0x4d7 > cs: IO port probe 0x0a00-0x0aff: clean. > cs: memory probe 0xa0000000-0xa0ffffff: clean. > > > ---------------- > the differences between the 2 .config files > > root@sven:/usr/src/2.5# diff linux-2.5.73/.config linux-2.5.74/.config > 174d173 > < CONFIG_BINFMT_AOUT=m > 175a175 > > CONFIG_BINFMT_AOUT=m > 178a179,183 > > # Generic Driver Options > > # > > # CONFIG_FW_LOADER is not set > > > > # > 350d354 > < # CONFIG_SCSI_NCR53C7xx is not set > 352d355 > < # CONFIG_SCSI_NCR53C8XX is not set > 711d713 > < # CONFIG_MOUSE_PS2_SYNAPTICS is not set > 747a750 > > # CONFIG_I2C_PROSAVAGE is not set > 758a762 > > # CONFIG_I2C_ALI1535 is not set > 774a779 > > # CONFIG_SENSORS_LM78 is not set > 1266a1272 > > # CONFIG_USB_AX8817X is not set > > > > > ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <20030905193811.C14076@flint.arm.linux.org.uk>]
* Re: Problems with PCMCIA (Texas Instruments PCI1450) [not found] ` <20030905193811.C14076@flint.arm.linux.org.uk> @ 2003-09-05 19:40 ` Daniel Ritz 2003-09-05 19:54 ` Russell King 0 siblings, 1 reply; 12+ messages in thread From: Daniel Ritz @ 2003-09-05 19:40 UTC (permalink / raw) To: Russell King, Sven Dowideit; +Cc: linux-kernel, Tom Marshall On Fri September 5 2003 20:38, Russell King wrote: > On Fri, Sep 05, 2003 at 08:19:28PM +0200, Daniel Ritz wrote: > > ok, now i can reproduce the problem on my ti1410 too. on boot detection > > works fine with an UP kernel and fails with an SMP kernel. thanx for the > > hint. > > > > i go to look at the csets a bit and try to find out more.... > > (i think i know which change...) > > Care to provide a hint? yes. just tested. patch below makes on boot detection with a SMP kernel working again (for me). which is nice, but i don't see why it is better that way... ===== cs.c 1.56 vs edited ===== --- 1.56/drivers/pcmcia/cs.c Sun Aug 3 14:48:43 2003 +++ edited/cs.c Fri Sep 5 21:42:09 2003 @@ -316,7 +316,6 @@ wait_for_completion(&socket->thread_done); BUG_ON(!socket->thread); - pcmcia_parse_events(socket, SS_DETECT); return 0; } @@ -1524,6 +1523,9 @@ if (client == NULL) return CS_OUT_OF_RESOURCE; + if (++s->real_clients == 1) + pcmcia_parse_events(s, SS_DETECT); + *handle = client; client->state &= ~CLIENT_UNBOUND; client->Socket = s; ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problems with PCMCIA (Texas Instruments PCI1450) 2003-09-05 19:40 ` Daniel Ritz @ 2003-09-05 19:54 ` Russell King 2003-09-05 20:17 ` Daniel Ritz 2003-09-06 16:41 ` [PATCH] " Russell King 0 siblings, 2 replies; 12+ messages in thread From: Russell King @ 2003-09-05 19:54 UTC (permalink / raw) To: Daniel Ritz; +Cc: Sven Dowideit, linux-kernel, Tom Marshall On Fri, Sep 05, 2003 at 09:40:27PM +0200, Daniel Ritz wrote: > On Fri September 5 2003 20:38, Russell King wrote: > > On Fri, Sep 05, 2003 at 08:19:28PM +0200, Daniel Ritz wrote: > > > ok, now i can reproduce the problem on my ti1410 too. on boot detection > > > works fine with an UP kernel and fails with an SMP kernel. thanx for the > > > hint. > > > > > > i go to look at the csets a bit and try to find out more.... > > > (i think i know which change...) > > > > Care to provide a hint? > > yes. just tested. patch below makes on boot detection with a SMP kernel > working again (for me). which is nice, but i don't see why it is better > that way... Ok, now I need to hear from Sven (and others) to see if this patch fixes their problems. Also, are these other people running a SMP kernel as well? Meanwhile, I'm wondering if we have a timing problem here. Can you check whether adding a mdelay(1) just after the BUG_ON in the original code fixes the problem? > ===== cs.c 1.56 vs edited ===== > --- 1.56/drivers/pcmcia/cs.c Sun Aug 3 14:48:43 2003 > +++ edited/cs.c Fri Sep 5 21:42:09 2003 > @@ -316,7 +316,6 @@ > > wait_for_completion(&socket->thread_done); > BUG_ON(!socket->thread); > - pcmcia_parse_events(socket, SS_DETECT); > > return 0; > } > @@ -1524,6 +1523,9 @@ > if (client == NULL) > return CS_OUT_OF_RESOURCE; > > + if (++s->real_clients == 1) > + pcmcia_parse_events(s, SS_DETECT); > + > *handle = client; > client->state &= ~CLIENT_UNBOUND; > client->Socket = s; > -- Russell King (rmk@arm.linux.org.uk) http://www.arm.linux.org.uk/personal/ Linux kernel maintainer of: 2.6 ARM Linux - http://www.arm.linux.org.uk/ 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problems with PCMCIA (Texas Instruments PCI1450) 2003-09-05 19:54 ` Russell King @ 2003-09-05 20:17 ` Daniel Ritz 2003-09-06 16:41 ` [PATCH] " Russell King 1 sibling, 0 replies; 12+ messages in thread From: Daniel Ritz @ 2003-09-05 20:17 UTC (permalink / raw) To: Russell King; +Cc: Sven Dowideit, linux-kernel, Tom Marshall On Fri September 5 2003 21:54, Russell King wrote: > On Fri, Sep 05, 2003 at 09:40:27PM +0200, Daniel Ritz wrote: > > On Fri September 5 2003 20:38, Russell King wrote: > > > On Fri, Sep 05, 2003 at 08:19:28PM +0200, Daniel Ritz wrote: > > > > ok, now i can reproduce the problem on my ti1410 too. on boot detection > > > > works fine with an UP kernel and fails with an SMP kernel. thanx for the > > > > hint. > > > > > > > > i go to look at the csets a bit and try to find out more.... > > > > (i think i know which change...) > > > > > > Care to provide a hint? > > > > yes. just tested. patch below makes on boot detection with a SMP kernel > > working again (for me). which is nice, but i don't see why it is better > > that way... > > Ok, now I need to hear from Sven (and others) to see if this patch fixes > their problems. Also, are these other people running a SMP kernel as > well? > > Meanwhile, I'm wondering if we have a timing problem here. Can you check > whether adding a mdelay(1) just after the BUG_ON in the original code > fixes the problem? no effect. i tried that before with loooong sleeps (1 second) w/o any effect... > > > ===== cs.c 1.56 vs edited ===== > > --- 1.56/drivers/pcmcia/cs.c Sun Aug 3 14:48:43 2003 > > +++ edited/cs.c Fri Sep 5 21:42:09 2003 > > @@ -316,7 +316,6 @@ > > > > wait_for_completion(&socket->thread_done); > > BUG_ON(!socket->thread); > > - pcmcia_parse_events(socket, SS_DETECT); > > > > return 0; > > } > > @@ -1524,6 +1523,9 @@ > > if (client == NULL) > > return CS_OUT_OF_RESOURCE; > > > > + if (++s->real_clients == 1) > > + pcmcia_parse_events(s, SS_DETECT); > > + > > *handle = client; > > client->state &= ~CLIENT_UNBOUND; > > client->Socket = s; > > > > -- > Russell King (rmk@arm.linux.org.uk) http://www.arm.linux.org.uk/personal/ > Linux kernel maintainer of: > 2.6 ARM Linux - http://www.arm.linux.org.uk/ > 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ > 2.6 Serial core > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] Re: Problems with PCMCIA (Texas Instruments PCI1450) 2003-09-05 19:54 ` Russell King 2003-09-05 20:17 ` Daniel Ritz @ 2003-09-06 16:41 ` Russell King 2003-09-07 19:33 ` Sven Dowideit 2003-09-08 22:30 ` Tom Marshall 1 sibling, 2 replies; 12+ messages in thread From: Russell King @ 2003-09-06 16:41 UTC (permalink / raw) To: Daniel Ritz, Sven Dowideit, linux-kernel, Tom Marshall On Fri, Sep 05, 2003 at 08:54:29PM +0100, Russell King wrote: > On Fri, Sep 05, 2003 at 09:40:27PM +0200, Daniel Ritz wrote: > > On Fri September 5 2003 20:38, Russell King wrote: > > > On Fri, Sep 05, 2003 at 08:19:28PM +0200, Daniel Ritz wrote: > > > > ok, now i can reproduce the problem on my ti1410 too. on boot detection > > > > works fine with an UP kernel and fails with an SMP kernel. thanx for the > > > > hint. > > > > > > > > i go to look at the csets a bit and try to find out more.... > > > > (i think i know which change...) > > > > > > Care to provide a hint? > > > > yes. just tested. patch below makes on boot detection with a SMP kernel > > working again (for me). which is nice, but i don't see why it is better > > that way... > > Ok, now I need to hear from Sven (and others) to see if this patch fixes > their problems. Also, are these other people running a SMP kernel as > well? Ok, I've updated pcmcia.arm.linux.org.uk with a couple of patches which should solve the real cause of problem - a nice race condition. I'm including the patch here - can people which this problem check whether it solves the problem on their hardware? I'd like to hear back from people who have been affected by this bug before I push this patch to Linus. Thanks. diff -ur ref/drivers/pcmcia/cs.c linux/drivers/pcmcia/cs.c --- ref/drivers/pcmcia/cs.c Tue Aug 5 11:19:39 2003 +++ linux/drivers/pcmcia/cs.c Sat Sep 6 15:07:25 2003 @@ -474,7 +474,7 @@ DEBUG(1, "cs: shutdown_socket(%p)\n", s); /* Blank out the socket state */ - s->state &= SOCKET_PRESENT|SOCKET_SETUP_PENDING; + s->state &= SOCKET_PRESENT|SOCKET_INUSE; s->socket = dead_socket; s->ops->init(s); s->irq.AssignedIRQ = s->irq.Config = 0; @@ -657,7 +657,6 @@ pcmcia_error(skt, "unsupported voltage key.\n"); return CS_BAD_TYPE; } - skt->state |= SOCKET_PRESENT; skt->socket.flags = SS_DEBOUNCED; skt->ops->set_socket(skt, &skt->socket); @@ -678,22 +677,23 @@ { int ret; - if (!try_module_get(skt->owner)) + if (!cs_socket_get(skt)) return CS_NO_CARD; ret = socket_setup(skt, setup_delay); if (ret == CS_SUCCESS) { + skt->state |= SOCKET_PRESENT; #ifdef CONFIG_CARDBUS if (skt->state & SOCKET_CARDBUS) { cb_alloc(skt); skt->state |= SOCKET_CARDBUS_CONFIG; } #endif send_event(skt, CS_EVENT_CARD_INSERTION, CS_EVENT_PRI_LOW); skt->socket.flags &= ~SS_DEBOUNCED; } else { socket_shutdown(skt); - module_put(skt->owner); + cs_socket_put(skt); } return ret; @@ -741,10 +741,8 @@ } skt->socket.flags &= ~SS_DEBOUNCED; } else { - unsigned int old_state = skt->state; socket_shutdown(skt); - if (old_state & SOCKET_PRESENT) - module_put(skt->owner); + cs_socket_put(skt); } skt->state &= ~SOCKET_SUSPEND; @@ -755,7 +753,7 @@ static void socket_remove(struct pcmcia_socket *skt) { socket_shutdown(skt); - module_put(skt->owner); + cs_socket_put(skt); } /* @@ -1346,8 +1344,6 @@ status->CardState |= CS_EVENT_PM_SUSPEND; if (!(s->state & SOCKET_PRESENT)) return CS_NO_CARD; - if (s->state & SOCKET_SETUP_PENDING) - status->CardState |= CS_EVENT_CARD_INSERTION; /* Get info from the PRR, if necessary */ if (handle->Function == BIND_FN_ALL) { @@ -1524,6 +1520,10 @@ if (client == NULL) return CS_OUT_OF_RESOURCE; + /* + * Prevent this racing with a card insertion. + */ + down(&s->skt_sem); *handle = client; client->state &= ~CLIENT_UNBOUND; client->Socket = s; @@ -1555,13 +1555,15 @@ client, client->Socket, client->dev_info); if (client->EventMask & CS_EVENT_REGISTRATION_COMPLETE) EVENT(client, CS_EVENT_REGISTRATION_COMPLETE, CS_EVENT_PRI_LOW); - if ((s->state & SOCKET_PRESENT) && - !(s->state & SOCKET_SETUP_PENDING)) { + + if ((s->state & (SOCKET_PRESENT|SOCKET_CARDBUS)) == SOCKET_PRESENT) { if (client->EventMask & CS_EVENT_CARD_INSERTION) EVENT(client, CS_EVENT_CARD_INSERTION, CS_EVENT_PRI_LOW); else client->PendingEvents |= CS_EVENT_CARD_INSERTION; } + + up(&s->skt_sem); return CS_SUCCESS; } /* register_client */ diff -ur ref/drivers/pcmcia/cs_internal.h linux/drivers/pcmcia/cs_internal.h --- ref/drivers/pcmcia/cs_internal.h Tue Aug 5 11:19:39 2003 +++ linux/drivers/pcmcia/cs_internal.h Sat Sep 6 14:41:19 2003 @@ -99,7 +99,7 @@ /* Flags in socket state */ #define SOCKET_PRESENT 0x0008 -#define SOCKET_SETUP_PENDING 0x0010 +#define SOCKET_INUSE 0x0010 #define SOCKET_SHUTDOWN_PENDING 0x0020 #define SOCKET_RESET_PENDING 0x0040 #define SOCKET_SUSPEND 0x0080 @@ -109,6 +109,26 @@ #define SOCKET_CARDBUS 0x8000 #define SOCKET_CARDBUS_CONFIG 0x10000 +static inline int cs_socket_get(struct pcmcia_socket *skt) +{ + int ret; + + WARN_ON(skt->state & SOCKET_INUSE); + + ret = try_module_get(skt->owner); + if (ret) + skt->state |= SOCKET_INUSE; + return ret; +} + +static inline void cs_socket_put(struct pcmcia_socket *skt) +{ + if (skt->state & SOCKET_INUSE) { + skt->state &= ~SOCKET_INUSE; + module_put(skt->owner); + } +} + #define CHECK_HANDLE(h) \ (((h) == NULL) || ((h)->client_magic != CLIENT_MAGIC)) -- Russell King (rmk@arm.linux.org.uk) http://www.arm.linux.org.uk/personal/ Linux kernel maintainer of: 2.6 ARM Linux - http://www.arm.linux.org.uk/ 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] Re: Problems with PCMCIA (Texas Instruments PCI1450) 2003-09-06 16:41 ` [PATCH] " Russell King @ 2003-09-07 19:33 ` Sven Dowideit 2003-09-08 22:30 ` Tom Marshall 1 sibling, 0 replies; 12+ messages in thread From: Sven Dowideit @ 2003-09-07 19:33 UTC (permalink / raw) To: Russell King; +Cc: Daniel Ritz, linux-kernel, Tom Marshall [-- Attachment #1: Type: text/plain, Size: 3189 bytes --] On Sun, 2003-09-07 at 02:41, Russell King wrote: > I'd like to hear back from people who have been affected by this bug > before I push this patch to Linus. it fixes my pcmcia problem at startup :) and for bonus points, it also when plugged into the docking station pcmcia cards (which is one up on the last 2.4 i used) when i get a chance I will put the pc-card bridge back into my dual processor piii, and see how that goes too.. is the PC-Card code supposed to work on SMP? > Thanks. no, thank you! in the process of playing around with cardctl eject, insert and pulling out the card without warning i have gotten the following.. airo: Doing fast bap_reads airo: MAC enabled eth1 0:40:96:33:e:a4 eth1: index 0x05: Vcc 5.0, Vpp 5.0, irq 3, io 0x0100-0x013f nfs warning: mount version older than kernel nfs: server 10.10.10.10 not responding, still trying nfs: server 10.10.10.10 OK nfs: server 10.10.10.10 not responding, still trying RPC: sendmsg returned error 101 nfs: RPC call returned error 101 RPC: sendmsg returned error 101 nfs: RPC call returned error 101 RPC: sendmsg returned error 101 nfs: RPC call returned error 101 airo: Probing for PCI adapters kobject_register failed for airo (-17) Call Trace: [<c0214da9>] kobject_register+0x59/0x60 [<c023c1e2>] bus_add_driver+0x52/0xb0 [<c021ef7e>] pci_register_driver+0x6e/0xa0 [<e08670e8>] airo_init_module+0xe8/0x10d [airo] [<c0139f0f>] sys_init_module+0x12f/0x260 [<c010b0db>] syscall_call+0x7/0xb airo: Finished probing for PCI adapters airo: Doing fast bap_reads airo: MAC enabled eth1 0:40:96:33:e:a4 eth1: index 0x05: Vcc 5.0, Vpp 5.0, irq 3, io 0x0100-0x013f airo: Probing for PCI adapters kobject_register failed for airo (-17) Call Trace: [<c0214da9>] kobject_register+0x59/0x60 [<c023c1e2>] bus_add_driver+0x52/0xb0 [<c021ef7e>] pci_register_driver+0x6e/0xa0 [<e08670e8>] airo_init_module+0xe8/0x10d [airo] [<c0139f0f>] sys_init_module+0x12f/0x260 [<c010b0db>] syscall_call+0x7/0xb airo: Finished probing for PCI adapters airo: Doing fast bap_reads airo: MAC enabled eth1 0:40:96:33:e:a4 eth1: index 0x05: Vcc 5.0, Vpp 5.0, irq 3, io 0x0100-0x013f irq 9: nobody cared! Call Trace: [<c010d45a>] __report_bad_irq+0x2a/0x90 [<c010d550>] note_interrupt+0x70/0xb0 [<c010d890>] do_IRQ+0x160/0x1a0 [<c010ba48>] common_interrupt+0x18/0x20 [<e087007b>] yenta_get_status+0x4b/0x110 [yenta_socket] [<c010d3e0>] handle_IRQ_event+0x30/0x80 [<c010d7e7>] do_IRQ+0xb7/0x1a0 [<c010ba48>] common_interrupt+0x18/0x20 [<e0828253>] apm_bios_call_simple+0x83/0x100 [apm] [<e0828437>] apm_do_idle+0x27/0x80 [apm] [<e0828572>] apm_cpu_idle+0xa2/0x140 [apm] [<c0105000>] _stext+0x0/0x70 [<c0108c8b>] cpu_idle+0x3b/0x50 [<c03ea919>] start_kernel+0x199/0x1d0 [<c03ea490>] unknown_bootoption+0x0/0x120 handlers: [<c0260f90>] (ide_intr+0x0/0x1e0) [<e08708b0>] (yenta_interrupt+0x0/0x40 [yenta_socket]) [<e08708b0>] (yenta_interrupt+0x0/0x40 [yenta_socket]) Disabling IRQ #9 > diff -ur ref/drivers/pcmcia/cs.c linux/drivers/pcmcia/cs.c > -- ref/drivers/pcmcia/cs.c Tue Aug 5 11:19:39 2003 > +++ linux/drivers/pcmcia/cs.c Sat Sep 6 15:07:25 2003 [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] Re: Problems with PCMCIA (Texas Instruments PCI1450) 2003-09-06 16:41 ` [PATCH] " Russell King 2003-09-07 19:33 ` Sven Dowideit @ 2003-09-08 22:30 ` Tom Marshall 1 sibling, 0 replies; 12+ messages in thread From: Tom Marshall @ 2003-09-08 22:30 UTC (permalink / raw) To: Daniel Ritz, Sven Dowideit, linux-kernel [-- Attachment #1: Type: text/plain, Size: 712 bytes --] > > Ok, now I need to hear from Sven (and others) to see if this patch fixes > > their problems. Also, are these other people running a SMP kernel as > > well? > > Ok, I've updated pcmcia.arm.linux.org.uk with a couple of patches which > should solve the real cause of problem - a nice race condition. I'm > including the patch here - can people which this problem check whether > it solves the problem on their hardware? > > I'd like to hear back from people who have been affected by this bug > before I push this patch to Linus. Seems to work for me. Thanks! :-) -- If voting could change the system, it would be illegal. If not voting could change the system, it would be illegal. [-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problems with PCMCIA (Texas Instruments PCI1410) 2003-08-26 22:56 Problems with PCMCIA (Texas Instruments PCI1410) Daniel Ritz 2003-08-27 12:59 ` Russell King @ 2003-08-27 23:04 ` Sven Dowideit 1 sibling, 0 replies; 12+ messages in thread From: Sven Dowideit @ 2003-08-27 23:04 UTC (permalink / raw) To: Daniel Ritz; +Cc: Tom Marshall, linux-kernel On Wed, 2003-08-27 at 08:56, Daniel Ritz wrote: > can you please retest with -test4 and russell's yenta patches? > http://patches.arm.linux.org.uk/pcmcia/yenta-20030817.tar > > if that doesn't work out: could you please add these lines to in yenta_socket.c? (this is the TI PCI1450) mmm it seems to work fine every time except if i boot with the card inserted. (same result as test4 only) this log (with the yenta patch) is from insertting and removing the card - cardctl insert and remove look the same.. sven...... Linux version 2.6.0-test4 (root@sven) (gcc version 3.3.2 20030812 (Debian prerelease)) #5 Thu Aug 28 08:02:48 EST 2003 Video mode to be used for restore is f00 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009f800 (usable) BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000001fff0000 (usable) BIOS-e820: 000000001fff0000 - 000000001fffec00 (ACPI data) BIOS-e820: 000000001fffec00 - 0000000020000000 (ACPI NVS) BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved) 511MB LOWMEM available. On node 0 totalpages: 131056 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 126960 pages, LIFO batch:16 HighMem zone: 0 pages, LIFO batch:1 DMI 2.3 present. IBM machine detected. Enabling interrupts during APM calls. IBM machine detected. Disabling SMBus accesses. ACPI: RSDP (v000 PTLTD ) @ 0x000f7120 ACPI: RSDT (v001 PTLTD RSDT 0x06041150 LTP 0x00000000) @ 0x1fff4c5d ACPI: FADT (v001 IBM TP-T21 0x06041150 0x00000000) @ 0x1fffeb65 ACPI: BOOT (v001 PTLTD $SBFTBL$ 0x06041150 LTP 0x00000001) @ 0x1fffebd9 ACPI: DSDT (v001 IBM TP-T21 0x06041150 MSFT 0x0100000c) @ 0x00000000 ACPI: MADT not present Building zonelist for node : 0 Kernel command line: BOOT_IMAGE=linux26 ro root=303 Local APIC disabled by BIOS -- reenabling. Could not enable APIC! Initializing CPU#0 PID hash table entries: 2048 (order 11: 16384 bytes) Detected 846.433 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1675.26 BogoMIPS Memory: 515036k/524224k available (2045k kernel code, 8444k reserved, 788k data, 160k init, 0k highmem) Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) -> /dev -> /dev/console -> /root CPU: After generic identify, caps: 0383f9ff 00000000 00000000 00000000 CPU: After vendor identify, caps: 0383f9ff 00000000 00000000 00000000 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K CPU: After all inits, caps: 0383f9ff 00000000 00000000 00000040 CPU: Intel Pentium III (Coppermine) stepping 06 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX PM: Adding info for No Bus:legacy Initializing RT netlink socket PCI: PCI BIOS revision 2.10 entry at 0xfd94f, last bus=7 PCI: Using configuration type 1 mtrr: v2.0 (20020519) BIO: pool of 256 setup, 14Kb (56 bytes/bio) biovec pool[0]: 1 bvecs: 256 entries (12 bytes) biovec pool[1]: 4 bvecs: 256 entries (48 bytes) biovec pool[2]: 16 bvecs: 256 entries (192 bytes) biovec pool[3]: 64 bvecs: 256 entries (768 bytes) biovec pool[4]: 128 bvecs: 256 entries (1536 bytes) biovec pool[5]: 256 bvecs: 256 entries (3072 bytes) PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) PM: Adding info for No Bus:pci0000:00 PM: Adding info for pci:0000:00:00.0 PM: Adding info for pci:0000:00:01.0 PM: Adding info for pci:0000:00:02.0 PM: Adding info for pci:0000:00:02.1 PM: Adding info for pci:0000:00:03.0 PM: Adding info for pci:0000:00:03.1 PM: Adding info for pci:0000:00:05.0 PM: Adding info for pci:0000:00:07.0 PM: Adding info for pci:0000:00:07.1 PM: Adding info for pci:0000:00:07.2 PM: Adding info for pci:0000:00:07.3 PM: Adding info for pci:0000:01:00.0 PM: Adding info for No Bus:pci0000:08 PCI: Discovered primary peer bus 08 [IRQ] PCI: Using IRQ router PIIX [8086/7110] at 0000:00:07.0 vga16fb: initializing vga16fb: mapped to 0xc00a0000 fb0: VGA16 VGA frame buffer device pty: 256 Unix98 ptys configured SBF: ACPI BOOT descriptor is wrong length (39) SBF: Simple Boot Flag extension found and enabled. SBF: Setting boot flags 0x1 cpufreq: Intel(R) SpeedStep(TM) for this chipset not (yet) available. ikconfig 0.5 with /proc/ikconfig VFS: Disk quotas dquot_6.5.1 Journalled Block Device driver loaded Limiting direct PCI/PCI transfers. Real Time Clock Driver v1.11a Using anticipatory scheduling elevator Floppy drive(s): fd0 is 1.44M FDC 0 is a National Semiconductor PC87306 PM: Adding info for platform:floppy0 RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: loaded (max 8 devices) Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PIIX4: IDE controller at PCI slot 0000:00:07.1 PIIX4: chipset revision 1 PIIX4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0x1c00-0x1c07, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0x1c08-0x1c0f, BIOS settings: hdc:DMA, hdd:pio hda: IC25T048ATDA05-0, ATA DISK drive PM: Adding info for No Bus:ide0 ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 PM: Adding info for ide:0.0 hdc: MATSHITADVD-ROM SR-8175, ATAPI CD/DVD-ROM drive PM: Adding info for No Bus:ide1 ide1 at 0x170-0x177,0x376 on irq 15 PM: Adding info for ide:1.0 hda: max request size: 128KiB hda: 93759120 sectors (48004 MB) w/1806KiB Cache, CHS=65535/16/63 hda: hda1 hda2 hda3 hda4 < hda5 hda6 > end_request: I/O error, dev hdc, sector 0 hdc: ATAPI 24X DVD-ROM drive, 512kB Cache Uniform CD-ROM driver Revision: 3.12 ide-floppy driver 0.99.newide mice: PS/2 mouse device common for all mice input: PS/2 Generic Mouse on isa0060/serio1 serio: i8042 AUX port at 0x60,0x64 irq 12 input: AT Set 2 keyboard on isa0060/serio0 serio: i8042 KBD port at 0x60,0x64 irq 1 I2O Core - (C) Copyright 1999 Red Hat Software I2O: Event thread created as pid 10 i2o: Checking for PCI I2O controllers... I2O configuration manager v 0.04. (C) Copyright 1999 Red Hat Software NET4: Linux TCP/IP 1.0 for NET4.0 IP: routing cache hash table of 4096 buckets, 32Kbytes TCP: Hash tables configured (established 32768 bind 65536) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Freeing unused kernel memory: 160k freed EXT3 FS on hda3, internal journal drivers/usb/core/usb.c: registered new driver usbfs drivers/usb/core/usb.c: registered new driver hub drivers/usb/core/usb.c: registered new driver usbkbd drivers/usb/input/usbkbd.c: :USB HID Boot Protocol keyboard driver airo: Probing for PCI adapters airo: Finished probing for PCI adapters apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac) PCI: Found IRQ 11 for device 0000:00:03.0 PCI: Sharing IRQ 11 with 0000:00:03.1 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html 0000:00:03.0: 3Com PCI 3c556B Laptop Hurricane at 0x1800. Vers LK1.1.19 kjournald starting. Commit interval 5 seconds EXT3 FS on hda6, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on hda2, internal journal EXT3-fs: mounted filesystem with ordered data mode. Linux Kernel Card Services 3.1.22 options: [pci] [cardbus] [pm] Intel PCIC probe: not found. PCI: Found IRQ 9 for device 0000:00:02.0 PCI: Sharing IRQ 9 with 0000:00:05.0 PCI: Sharing IRQ 9 with 0000:01:00.0 Yenta: CardBus bridge found at 0000:00:02.0 [1014:0130] Yenta: Using INTVAL to route CSC interrupts to PCI Yenta: Routing CardBus interrupts to PCI Yenta: ISA IRQ list 00b8, PCI irq9 Socket status: 30000010 PCI: Found IRQ 9 for device 0000:00:02.1 Yenta: CardBus bridge found at 0000:00:02.1 [1014:0130] Yenta: Using INTVAL to route CSC interrupts to PCI Yenta: Routing CardBus interrupts to PCI Yenta: ISA IRQ list 00b8, PCI irq9 Socket status: 30000006 yenta_get_status: socket dfafdc00, state: 30000410 yenta_get_status: socket dfafdc00, state: 30000410 yenta_get_status: socket dfafd000, state: 30000086 yenta_get_status: socket dfafdc00, state: 30000410 yenta_get_status: socket dfafdc00, state: 30000419 cs: IO port probe 0x0c00-0x0cff: clean. cs: IO port probe 0x0800-0x08ff: clean. cs: IO port probe 0x0100-0x04ff: excluding 0x378-0x37f 0x3c0-0x3df 0x4d0-0x4d7 cs: IO port probe 0x0a00-0x0aff: clean. cs: memory probe 0xa0000000-0xa0ffffff: clean. yenta_get_status: socket dfafdc00, state: 30000419 yenta_get_status: socket dfafdc00, state: 30000419 yenta_get_status: socket dfafdc00, state: 30000419 yenta_get_status: socket dfafdc00, state: 30000459 yenta_get_status: socket dfafdc00, state: 30000459 yenta_events: socket dfafdc00, cb: 0, csc: 8 yenta_events: socket dfafd000, cb: 0, csc: 0 yenta_events: socket dfafdc00, cb: 6, csc: 0 yenta_events: socket dfafd000, cb: 0, csc: 0 yenta_get_status: socket dfafdc00, state: 3000011f yenta_events: socket dfafdc00, cb: c, csc: 0 yenta_events: socket dfafd000, cb: 0, csc: 0 yenta_events: socket dfafdc00, cb: 4, csc: 0 yenta_events: socket dfafd000, cb: 0, csc: 0 yenta_get_status: socket dfafdc00, state: 30000086 yenta_events: socket dfafdc00, cb: 0, csc: 8 yenta_events: socket dfafd000, cb: 0, csc: 0 yenta_events: socket dfafdc00, cb: 6, csc: 0 yenta_events: socket dfafd000, cb: 0, csc: 0 yenta_get_status: socket dfafdc00, state: 30000410 yenta_get_status: socket dfafdc00, state: 30000410 yenta_get_status: socket dfafdc00, state: 30000410 yenta_get_status: socket dfafdc00, state: 30000419 yenta_get_status: socket dfafdc00, state: 30000419 yenta_get_status: socket dfafdc00, state: 30000419 yenta_get_status: socket dfafdc00, state: 30000459 yenta_get_status: socket dfafdc00, state: 30000459 yenta_get_status: socket dfafdc00, state: 30000459 airo: Doing fast bap_reads airo: MAC enabled eth1 0:40:96:33:e:a4 eth1: index 0x05: Vcc 5.0, Vpp 5.0, irq 3, io 0x0100-0x013f yenta_events: socket dfafdc00, cb: 0, csc: 8 yenta_events: socket dfafd000, cb: 0, csc: 0 yenta_events: socket dfafdc00, cb: 6, csc: 0 yenta_events: socket dfafd000, cb: 0, csc: 0 yenta_get_status: socket dfafdc00, state: 3000001f yenta_events: socket dfafdc00, cb: 4, csc: 0 yenta_events: socket dfafd000, cb: 0, csc: 0 yenta_get_status: socket dfafdc00, state: 3000028a yenta_events: socket dfafdc00, cb: 4, csc: 0 yenta_events: socket dfafd000, cb: 0, csc: 0 yenta_get_status: socket dfafdc00, state: 3000028e yenta_events: socket dfafdc00, cb: c, csc: 0 yenta_events: socket dfafd000, cb: 0, csc: 0 yenta_events: socket dfafdc00, cb: 4, csc: 0 yenta_events: socket dfafd000, cb: 0, csc: 0 yenta_get_status: socket dfafdc00, state: 30000286 yenta_events: socket dfafdc00, cb: 0, csc: 8 yenta_events: socket dfafd000, cb: 0, csc: 0 yenta_events: socket dfafdc00, cb: 6, csc: 0 yenta_events: socket dfafd000, cb: 0, csc: 0 yenta_get_status: socket dfafdc00, state: 30000610 yenta_get_status: socket dfafdc00, state: 30000610 yenta_get_status: socket dfafdc00, state: 30000610 yenta_get_status: socket dfafdc00, state: 30000619 yenta_get_status: socket dfafdc00, state: 30000619 yenta_get_status: socket dfafdc00, state: 30000619 yenta_get_status: socket dfafdc00, state: 30000659 yenta_get_status: socket dfafdc00, state: 30000659 yenta_get_status: socket dfafdc00, state: 30000659 airo: Probing for PCI adapters kobject_register failed for airo (-17) Call Trace: [<c0201f59>] kobject_register+0x59/0x60 [<c02281b2>] bus_add_driver+0x52/0xb0 [<c022862f>] driver_register+0x2f/0x40 [<c0184094>] create_proc_entry+0x84/0xd0 [<c020bd5c>] pci_register_driver+0x5c/0x90 [<e08790e8>] airo_init_module+0xe8/0x10d [airo] [<c0133d98>] sys_init_module+0x118/0x230 [<c010ae9b>] syscall_call+0x7/0xb airo: Finished probing for PCI adapters airo: Doing fast bap_reads airo: MAC enabled eth1 0:40:96:33:e:a4 eth1: index 0x05: Vcc 5.0, Vpp 5.0, irq 3, io 0x0100-0x013f yenta_events: socket dfafdc00, cb: 0, csc: 8 yenta_events: socket dfafd000, cb: 0, csc: 0 yenta_events: socket dfafdc00, cb: 6, csc: 0 yenta_events: socket dfafd000, cb: 0, csc: 0 yenta_get_status: socket dfafdc00, state: 3000021f yenta_events: socket dfafdc00, cb: 4, csc: 0 yenta_events: socket dfafd000, cb: 0, csc: 0 yenta_get_status: socket dfafdc00, state: 3000028a yenta_events: socket dfafdc00, cb: 4, csc: 0 yenta_events: socket dfafd000, cb: 0, csc: 0 yenta_get_status: socket dfafdc00, state: 3000028e yenta_events: socket dfafdc00, cb: c, csc: 0 yenta_events: socket dfafd000, cb: 0, csc: 0 yenta_events: socket dfafdc00, cb: 4, csc: 0 yenta_events: socket dfafd000, cb: 0, csc: 0 yenta_get_status: socket dfafdc00, state: 30000286 yenta_get_status: socket dfafdc00, state: 30000286 yenta_events: socket dfafdc00, cb: 0, csc: 8 yenta_events: socket dfafd000, cb: 0, csc: 0 yenta_events: socket dfafdc00, cb: 6, csc: 0 yenta_events: socket dfafd000, cb: 0, csc: 0 yenta_get_status: socket dfafdc00, state: 30000610 yenta_get_status: socket dfafdc00, state: 30000610 yenta_get_status: socket dfafdc00, state: 30000610 yenta_get_status: socket dfafdc00, state: 30000619 yenta_get_status: socket dfafdc00, state: 30000619 yenta_get_status: socket dfafdc00, state: 30000619 yenta_get_status: socket dfafdc00, state: 30000659 yenta_get_status: socket dfafdc00, state: 30000659 airo: Probing for PCI adapters kobject_register failed for airo (-17) Call Trace: [<c0201f59>] kobject_register+0x59/0x60 [<c02281b2>] bus_add_driver+0x52/0xb0 [<c022862f>] driver_register+0x2f/0x40 [<c0184094>] create_proc_entry+0x84/0xd0 [<c020bd5c>] pci_register_driver+0x5c/0x90 [<e08790e8>] airo_init_module+0xe8/0x10d [airo] [<c0133d98>] sys_init_module+0x118/0x230 [<c010ae9b>] syscall_call+0x7/0xb airo: Finished probing for PCI adapters airo: Doing fast bap_reads airo: MAC enabled eth1 0:40:96:33:e:a4 eth1: index 0x05: Vcc 5.0, Vpp 5.0, irq 3, io 0x0100-0x013f yenta_events: socket dfafdc00, cb: 0, csc: 8 yenta_events: socket dfafd000, cb: 0, csc: 0 yenta_events: socket dfafdc00, cb: 6, csc: 0 yenta_events: socket dfafd000, cb: 0, csc: 0 yenta_get_status: socket dfafdc00, state: 3000021f ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2003-09-08 22:32 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-08-26 22:56 Problems with PCMCIA (Texas Instruments PCI1410) Daniel Ritz
2003-08-27 12:59 ` Russell King
2003-09-05 21:53 ` Problems with PCMCIA (Texas Instruments PCI1450) Sven Dowideit
2003-09-05 17:58 ` Russell King
2003-09-05 18:19 ` Daniel Ritz
[not found] ` <20030905193811.C14076@flint.arm.linux.org.uk>
2003-09-05 19:40 ` Daniel Ritz
2003-09-05 19:54 ` Russell King
2003-09-05 20:17 ` Daniel Ritz
2003-09-06 16:41 ` [PATCH] " Russell King
2003-09-07 19:33 ` Sven Dowideit
2003-09-08 22:30 ` Tom Marshall
2003-08-27 23:04 ` Problems with PCMCIA (Texas Instruments PCI1410) Sven Dowideit
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).