linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave <kilroyd@googlemail.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Dave <kilroyd@googlemail.com>,
	Andrey Borzenkov <arvidjaar@mail.ru>,
	orinoco-devel@lists.sourceforge.net,
	linux-pcmcia@lists.infradead.org, linux-wireless@vger.kernel.org,
	Dominik Brodowski <linux@dominikbrodowski.net>
Subject: Re: [Orinoco-devel] 2.6.28-rc2: new PCMCIA device instance after resume - orinoco can't download firmware
Date: Wed, 29 Oct 2008 20:53:24 +0000	[thread overview]
Message-ID: <4908CD44.8070503@gmail.com> (raw)
In-Reply-To: <200810292143.06027.rjw@sisk.pl>

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.

  reply	other threads:[~2008-10-29 20:53 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-28 19:19 2.6.28-rc2: new PCMCIA device instance after resume - orinoco can't download firmware Andrey Borzenkov
2008-10-29  0:42 ` Dominik Brodowski
2008-10-29  3:43   ` Andrey Borzenkov
2008-10-29 12:18     ` Rafael J. Wysocki
2008-10-29 15:19       ` Andrey Borzenkov
2008-10-29 18:49         ` [Orinoco-devel] " Dave
2008-10-29 20:43           ` Rafael J. Wysocki
2008-10-29 20:53             ` Dave [this message]
2008-10-29 21:34               ` Rafael J. Wysocki
2008-10-29 21:51               ` Russell King
2008-10-30 18:15                 ` Dave
2008-10-30 18:39                   ` Andrey Borzenkov
2008-10-30 22:46                     ` Rafael J. Wysocki
2008-10-29  0:49 ` Dave

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4908CD44.8070503@gmail.com \
    --to=kilroyd@googlemail.com \
    --cc=arvidjaar@mail.ru \
    --cc=linux-pcmcia@lists.infradead.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linux@dominikbrodowski.net \
    --cc=orinoco-devel@lists.sourceforge.net \
    --cc=rjw@sisk.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).