yenta-socket oops with 2.5.73-mm3, 2.5.74, 2.5.74-mm1

modprobe yenta-socket produces oops below _only_ after cold boot and _only_ when e100 loaded. No PCMCIA problems with this system with 2.4 and 2.5 until recent PCMCIA rework.

Reproduced behavior with 2.5.73-mm3, 2.5.74, 2.5.74-mm1

2.5.73-mm2 no oops but hangs about 1 in 10 at
PCI: Enabling device 0:12.0 (0->2) (PCMCIA). e100 was loaded but not
tested wo e100

Conditions:
Cold-boot - no oops when warm-boot+load after successful load or when
unload+load e100 loaded

Oops appears 1 in 4 loads and looks similar every time

Setup:
ACPI core enabled, no usb

$ lsmod
pcmcia_core
toshiba_acpi
e100

$ lspci
00:00.0 Host bridge: Transmeta Corporation LongRun Northbridge (rev 01)
00:00.1 RAM memory: Transmeta Corporation SDRAM controller
00:00.2 RAM memory: Transmeta Corporation BIOS scratchpad
00:04.0 VGA compatible controller: S3 Inc. 86C270-294 Savage/IX-MV (rev 13)
00:06.0 Multimedia audio controller: ALi Corporation M5451 PCI AC-Link
Controller Audio Device (rev 01) 00:07.0 ISA bridge: ALi Corporation M1533
PCI to ISA Bridge [Aladdin IV] 00:0e.0 Ethernet controller: Intel Corp.
82557/8/9 [Ethernet Pro 100] (rev 08) 00:10.0 IDE interface: ALi
Corporation M5229 IDE (rev c3)
00:11.0 Bridge: ALi Corporation M7101 PMU
00:12.0 CardBus bridge: Toshiba America Info Systems ToPIC95 PCI to Cardbus
Bridge with ZV Support (rev 32) 00:14.0 USB Controller: ALi Corporation USB
1.1 Controller (rev 03)

No serial port, Oops taken from screen
unable to handle null pointer dereference at 0
oops: 0000 #1
EFLAGS 00010086
EIP is at __wake_up_common+0x13
eax ce09c9c0 ebx 286 ecx 1 edx 0
esi 1 edi 0 ebp ccc67dcc esp ccc67dc0
ds 7b es 7b ss 68
Process modprobe pid 1153 threadinfo ccc66000 task cd68e080

Stack: 286 4000001 0 ccc67de8 c011afa1 ce09c9c0 3 1
       0 ce09c800 ccc67df0 cf8a3ecf cccc67e04 cf87a7ea ce09c830 80
       cdffec00 ccc67e24 c010d0aa 5 ce09c800 ccc67e50 280 5
Call trace:
__wake_up+0x11
pcmcia_parse_events+0x23
yenta_interrupt+0x26
handle_IRQ_event+0x2a
do_IRQ+0x82
common_interrupt+0x18
setup_irq+0x9b
yenta_interrupt+0x0
request_irq+0x89
yenta_probe+0x137
yenta_interrupt+0x0
pci_device_probe_static+0x20
pci_device_probe+0x21
bus_match+0x38
driver_attach+0x3e
bus_add_driver+0x6e
driver_register+0x36
pci_register_driver+0x6a
yenta_socket_init+0xd
sys_init_module+0xe0
syscall_call+0x7
Code: 8b 3a 8b 45 08 83 c0 04 39 c2 74 23 8b 5a f4 8b 4d 14 51 8b
 <0> Fatal exception in interrupt

In interrupt handler - not syncing

It is now running allright by starting pcmcia ahead of network.

hello

problem is that an interrupt arrives before socket->thread_wait is initialized so we crash in __wake_up_common. i think source of the interrupt is socket_init called before the initialization. but an interrupt can still arrive before...

i think the whole init stuff should happen even before we do request_irq(). i tried moving around pcmcia_register_socket() but then my card doesn't come up... maybe we should add something like pcmcia_alloc_socket() which does kmalloc() a socket struct and does all the important init stuff? russel?

michael, can you try this one?

rgds

(quoted diff) +0 -1

-daniel

cs.c renamed from drivers/pcmcia/cs.c +3 -3

@@ -338,13 +338,13 @@
 	socket->erase_busy.next = socket->erase_busy.prev = &socket->erase_busy;
 	INIT_LIST_HEAD(&socket->cis_cache);
 	spin_lock_init(&socket->lock);
-
-	init_socket(socket);
-
 	init_completion(&socket->thread_done);
 	init_waitqueue_head(&socket->thread_wait);
 	init_MUTEX(&socket->skt_sem);
 	spin_lock_init(&socket->thread_lock);
+
+	init_socket(socket);
+
 	ret = kernel_thread(pccardd, socket, CLONE_KERNEL);
 	if (ret < 0)
 		return ret;

Quoted 78 lines · Michael Frank

modprobe yenta-socket produces oops below _only_ after cold boot and _only_ when e100 loaded. No PCMCIA problems with this system with 2.4 and 2.5 until recent PCMCIA rework.

Reproduced behavior with 2.5.73-mm3, 2.5.74, 2.5.74-mm1

2.5.73-mm2 no oops but hangs about 1 in 10 at
PCI: Enabling device 0:12.0 (0->2) (PCMCIA). e100 was loaded but not
tested wo e100

Conditions:
Cold-boot - no oops when warm-boot+load after successful load or when
unload+load e100 loaded

Oops appears 1 in 4 loads and looks similar every time

Setup:
ACPI core enabled, no usb

$ lsmod
pcmcia_core
toshiba_acpi
e100

$ lspci
00:00.0 Host bridge: Transmeta Corporation LongRun Northbridge (rev 01)
00:00.1 RAM memory: Transmeta Corporation SDRAM controller
00:00.2 RAM memory: Transmeta Corporation BIOS scratchpad
00:04.0 VGA compatible controller: S3 Inc. 86C270-294 Savage/IX-MV (rev
13) 00:06.0 Multimedia audio controller: ALi Corporation M5451 PCI
AC-Link Controller Audio Device (rev 01) 00:07.0 ISA bridge: ALi
Corporation M1533 PCI to ISA Bridge [Aladdin IV] 00:0e.0 Ethernet
controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08) 00:10.0 IDE
interface: ALi Corporation M5229 IDE (rev c3)
00:11.0 Bridge: ALi Corporation M7101 PMU
00:12.0 CardBus bridge: Toshiba America Info Systems ToPIC95 PCI to
Cardbus Bridge with ZV Support (rev 32) 00:14.0 USB Controller: ALi
Corporation USB 1.1 Controller (rev 03)

No serial port, Oops taken from screen
unable to handle null pointer dereference at 0
oops: 0000 #1
EFLAGS 00010086
EIP is at __wake_up_common+0x13
eax ce09c9c0 ebx 286 ecx 1 edx 0
esi 1 edi 0 ebp ccc67dcc esp ccc67dc0
ds 7b es 7b ss 68
Process modprobe pid 1153 threadinfo ccc66000 task cd68e080

Stack: 286 4000001 0 ccc67de8 c011afa1 ce09c9c0 3 1
       0 ce09c800 ccc67df0 cf8a3ecf cccc67e04 cf87a7ea ce09c830 80
       cdffec00 ccc67e24 c010d0aa 5 ce09c800 ccc67e50 280 5
Call trace:
__wake_up+0x11
pcmcia_parse_events+0x23
yenta_interrupt+0x26
handle_IRQ_event+0x2a
do_IRQ+0x82
common_interrupt+0x18
setup_irq+0x9b
yenta_interrupt+0x0
request_irq+0x89
yenta_probe+0x137
yenta_interrupt+0x0
pci_device_probe_static+0x20
pci_device_probe+0x21
bus_match+0x38
driver_attach+0x3e
bus_add_driver+0x6e
driver_register+0x36
pci_register_driver+0x6a
yenta_socket_init+0xd
sys_init_module+0xe0
syscall_call+0x7
Code: 8b 3a 8b 45 08 83 c0 04 39 c2 74 23 8b 5a f4 8b 4d 14 51 8b
 <0> Fatal exception in interrupt

In interrupt handler - not syncing

It is now running allright by starting pcmcia ahead of network.

I got the patch below (not yet tested) from Dominik.

Quoted 1 line · Michael Frank

I got the patch below (not yet tested) from Dominik.

I've already thrown this one out and suggested a cleaner alternative to Dominik.

I was busy wasting time trying to get an XScale platform up and running yesterday, and getting nowhere fast. Going nowhere at all is a very accurate description of yesterdays activities. I suspect the hardware may have been messed up during transit thanks to various screws missing.

problem is that an interrupt arrives before socket->thread_wait is initialized so we crash in __wake_up_common. i think source of the interrupt is socket_init called before the initialization. but an interrupt can still arrive before...

michael, can you try this one?

Quoted 4 lines · Daniel Ritz

problem is that an interrupt arrives before socket->thread_wait is initialized so we crash in __wake_up_common. i think source of the interrupt is socket_init called before the initialization. but an interrupt can still arrive before...

I suspect that even with your patch below, there is the posibility to receive an unintentional call into pcmcia_parse_events() from some socket drivers. The all round better fix is to make pcmcia_parse_events() ignore socket change events until the socket thread is up and running.

Nevertheless, the patch looks correct, so I am still interested in whether your patch helps solve Michael's problem.

Quoted 1 line

michael, can you try this one?

Daniel's patch:

cs.c renamed from drivers/pcmcia/cs.c +3 -3

@@ -338,13 +338,13 @@
 	socket->erase_busy.next = socket->erase_busy.prev = &socket->erase_busy;
 	INIT_LIST_HEAD(&socket->cis_cache);
 	spin_lock_init(&socket->lock);
-
-	init_socket(socket);
-
 	init_completion(&socket->thread_done);
 	init_waitqueue_head(&socket->thread_wait);
 	init_MUTEX(&socket->skt_sem);
 	spin_lock_init(&socket->thread_lock);
+
+	init_socket(socket);
+
 	ret = kernel_thread(pccardd, socket, CLONE_KERNEL);
 	if (ret < 0)
 		return ret;

and my patch (may apply with some offset, which I'm about to check into bk anyway):

drivers/pcmcia/cs.c renamed from drivers/pcmcia/cs.c.old +6 -4

@@ -870,11 +870,13 @@
 
 void pcmcia_parse_events(struct pcmcia_socket *s, u_int events)
 {
-	spin_lock(&s->thread_lock);
-	s->thread_events |= events;
-	spin_unlock(&s->thread_lock);
+	if (s->thread) {
+		spin_lock(&s->thread_lock);
+		s->thread_events |= events;
+		spin_unlock(&s->thread_lock);
 
-	wake_up(&s->thread_wait);
+		wake_up(&s->thread_wait);
+	}
 } /* pcmcia_parse_events */

michael, can you try this one?

2.5.74-mm3 yenta-socket oopsed on the first boot at the same spot.

I have successfully used both patches below with -mm1.

cs.c Sat Jul 5 23:58:07 2003 renamed from drivers/pcmcia/cs.c Mon Jun 30 22:22:30 2003 +0 -3

@@ -338,13 +338,13 @@
        socket->erase_busy.next = socket->erase_busy.prev = &socket->erase_busy;
        INIT_LIST_HEAD(&socket->cis_cache);
        spin_lock_init(&socket->lock);
-
-       init_socket(socket);
-

and my patch (may apply with some offset, which I'm about to check into bk anyway):

drivers/pcmcia/cs.c Sun Jul 6 23:04:10 2003 renamed from drivers/pcmcia/cs.c.old Fri Jul 4 10:21:50 2003 +0 -2

@@ -870,11 +870,13 @@
 
 void pcmcia_parse_events(struct pcmcia_socket *s, u_int events)
 {
-       spin_lock(&s->thread_lock);
-       s->thread_events |= events;

Quoted 13 lines · Michael Frank

2.5.74-mm3 yenta-socket oopsed on the first boot at the same spot.

I have successfully used both patches below with -mm1.

cs.c Sat Jul 5 23:58:07 2003 renamed from drivers/pcmcia/cs.c Mon Jun 30 22:22:30 2003 +0 -3

@@ -338,13 +338,13 @@
        socket->erase_busy.next = socket->erase_busy.prev =
 &socket->erase_busy; INIT_LIST_HEAD(&socket->cis_cache);
        spin_lock_init(&socket->lock);
-
-       init_socket(socket);
-

cs.c Sat Jul 5 23:58:07 2003 line 350

Quoted 10 lines

cs.c Sat Jul 5 23:58:07 2003 renamed from drivers/pcmcia/cs.c Mon Jun 30 22:22:30 2003 +3 -0

        init_completion(&socket->thread_done);
        init_waitqueue_head(&socket->thread_wait);
        init_MUTEX(&socket->skt_sem);
        spin_lock_init(&socket->thread_lock);
+
+       init_socket(socket);
+
        ret = kernel_thread(pccardd, socket, CLONE_KERNEL);
        if (ret < 0)
                return ret;

This one is clearly correct.

Quoted 17 lines

and my patch (may apply with some offset, which I'm about to check into bk anyway):

drivers/pcmcia/cs.c Sun Jul 6 23:04:10 2003 renamed from drivers/pcmcia/cs.c.old Fri Jul 4 10:21:50 2003 +4 -3

@@ -870,11 +870,13 @@
 
 void pcmcia_parse_events(struct pcmcia_socket *s, u_int events)
 {
-       spin_lock(&s->thread_lock);
-       s->thread_events |= events;
-       spin_unlock(&s->thread_lock);
+       if (s->thread) {
+               spin_lock(&s->thread_lock);
+               s->thread_events |= events;
+               spin_unlock(&s->thread_lock);
 

drivers/pcmcia/cs.c Sun Jul 6 23:04:10 2003 line 880

Quoted 4 lines

drivers/pcmcia/cs.c Sun Jul 6 23:04:10 2003 renamed from drivers/pcmcia/cs.c.old Fri Jul 4 10:21:50 2003 +2 -1

-       wake_up(&s->thread_wait);
+               wake_up(&s->thread_wait);
+       }
 } /* pcmcia_parse_events */

This one may not be. How did we get here with no thread to handle the event? Do you have an oops trace on this one?

Or just stick a

	if (!s->thread)
		dump_stack();

in there as well.

Is called from interrupt handler. Seems that events occur before the
thread is created.

This one may not be. How did we get here with no thread to handle the event? Do you have an oops trace on this one?