On Wednesday, 29 of October 2008, Dave wrote:

Rafael J. Wysocki wrote:

quoted

On Wednesday, 29 of October 2008, Dave wrote:

quoted

Andrey Borzenkov wrote:

quoted

On Wednesday 29 October 2008, Rafael J. Wysocki wrote:

quoted

quoted

Do you have any idea what could it be? Original message is here:
http://marc.info/?l=linux-wireless&m=122522165719760&w=2

This probably is a result of the fact that we don't include firmware blobs
into modular drivers any more.  Please try to compile your driver directly
into the kernel and enable CONFIG_FIRMWARE_IN_KERNEL.

If this helps, we'll know what the problem is.

Ehh ... you miss the point. The problem is NOT missing firmware (I have
already been running with external firmware just fine in 2.6.27). The
problem is that during resume instead of simply resume *existing*
device/driver instance PCMCIA suddenly decides to re-discover the *same*
device yet another again.

bisecting will
take ages here. I need some advice which options to turn on.

I attempted to bisect, but ran into problems. As an alternative, I added
a WARN_ON(err) immediately after the request_firmware call to get a
stack dump:

orinoco_cs 0.0: firmware: requesting agere_sta_fw.bin
------------[ cut here ]------------
WARNING: at
/usr/src/linux-current/wireless-testing/drivers/net/wireless/orinoco.c:495
orinoco_dl_firmware+0xbb/0x1ce [orinoco]()
Modules linked in: orinoco_cs orinoco hermes_dld hermes michael_mic
aty128fb snd_maestro3 [last unloaded: hermes]
Pid: 22157, comm: bash Not tainted 2.6.28-rc2-wl #41
Call Trace:
 [<c0117a8c>] warn_on_slowpath+0x3e/0x57
 [<c019578a>] release_sysfs_dirent+0x50/0x60
 [<c0195b3d>] sysfs_addrm_finish+0x73/0x78
 [<c0195d03>] remove_dir+0x21/0x27
 [<c02a8901>] fw_dev_release+0x15/0x1d
 [<c022cfbe>] kobject_release+0x0/0x5
 [<c022d68b>] kref_put+0x3f/0x4c
 [<c02a8c7d>] _request_firmware+0x176/0x1bd
 [<d1083381>] orinoco_dl_firmware+0xbb/0x1ce [orinoco]
 [<d10836d0>] orinoco_download+0x1f/0x30 [orinoco]
 [<d1086b39>] orinoco_init+0x63/0x4aa [orinoco]
 [<c0362ee8>] __dev_get_by_name+0x18/0x72
 [<c03632ed>] __dev_alloc_name+0x110/0x128
 [<c03660e5>] netdev_init_queue_locks+0x29/0x41
 [<c03661e6>] register_netdevice+0x60/0x1d7
 [<c036638c>] register_netdev+0x2f/0x3b
 [<d10912a0>] orinoco_cs_config+0xe1/0x174 [orinoco_cs]
 [<c02ecdda>] pcmcia_device_probe+0xfa/0x144
 [<c0196200>] sysfs_do_create_link+0x3c/0x10f
 [<c02a559e>] __device_attach+0x0/0x5
 [<c02a54d9>] really_probe+0x70/0xea
 [<c02a5596>] driver_probe_device+0x34/0x3c
 [<c02a4a53>] bus_for_each_drv+0x38/0x59
 [<c02a55ee>] device_attach+0x4b/0x5e
 [<c02a559e>] __device_attach+0x0/0x5
 [<c02a4c00>] bus_attach_device+0x21/0x4f
 [<c02a3955>] device_add+0x147/0x272
 [<c02ed29b>] pcmcia_device_add+0x1ca/0x253
 [<c02ed3a1>] pcmcia_card_add+0x7d/0x8a       <----- ??
 [<c0112185>] dequeue_task_fair+0xf/0x10
 [<c0101c8d>] __switch_to+0x1d/0x139
 [<c011407b>] finish_task_switch+0x22/0x66
 [<c03e18fb>] __sched_text_start+0x2d3/0x2ec
 [<c022cf6d>] kobject_get+0xf/0x13
 [<c02a3a9e>] get_device+0xe/0x14
 [<c02e928a>] pcmcia_get_socket+0xe/0x7e
 [<c02edf0e>] ds_event+0x77/0x94
 [<c02e96b1>] send_event+0x84/0x9d
 [<c02e9bee>] socket_resume+0xa1/0xb5
 [<c02e9255>] pcmcia_socket_dev_resume+0x49/0x70
 [<c0238d42>] pci_legacy_resume+0x13/0x1a
 [<c0238e81>] pci_pm_resume+0x42/0x46
 [<c02a7887>] pm_op+0x2b/0x48
 [<c02a7a42>] resume_device+0x2e/0xa8
 [<c02a7b21>] dpm_resume+0x65/0xfc
 [<c02a7cf1>] device_resume+0x8/0x10
 [<c0135173>] suspend_devices_and_enter+0x72/0xa1
 [<c013521d>] enter_state+0x62/0x7a
 [<c013533f>] state_store+0x9f/0xb4
 [<c01352a0>] state_store+0x0/0xb4
 [<c022d0b8>] kobj_attr_store+0x18/0x1c
 [<c0194cf1>] flush_write_buffer+0x38/0x4c
 [<c0194d37>] sysfs_write_file+0x32/0x51
 [<c015eb9b>] vfs_write+0x81/0xf3
 [<c015ecab>] sys_write+0x3c/0x62
 [<c0102ced>] sysenter_do_call+0x12/0x21
---[ end trace 596cca76ed6aae6a ]---
eth1: Cannot find firmware agere_sta_fw.bin

?? Is that supposed to happen on resume?

Hm, what exactly do you mean?

I mean that from pcmcia_socket_dev_resume (shortly after resuming from
STR) we somehow get to pcmcia_card_add which results in a call to
orinoco_cs_config and orinoco_init.

Basically we have a completely new device. orinoco_init calls
request_firmware which fails under resume (because it tries to get
firmware from userspace), but is OK on normal startup. Andreys code to
load firmware after resume will only work when we call orinoco_cs_resume
for the device that got suspended, not if we see a new device.

Looking at the pcmcia code it looks like ds_event is getting a
CS_EVENT_CARD_INSERTION event. Should we be processing that event ?

Has suspend/resume of pcmcia devices changed so that they are detached
on suspend and enumerated on resume?

Well, I don't know.

Thanks,
Rafael