Rafael J. Wysocki wrote: > On Wednesday, 29 of October 2008, Dave wrote: >> Andrey Borzenkov wrote: >>> On Wednesday 29 October 2008, Rafael J. Wysocki wrote: >>>>> 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? Regards, Dave. PS. compiling the firmware blob into the kernel does allow the device to correctly restart. However it does so via orinoco_init, not orinoco_cs_resume. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
