Dear Wireless Developers,
I just had the following crash in p54common. The "failed to update LEDs" messages continued until I rebooted - couldn't find a way to reload the stack. O/S is ClearOS Community release 6.3.0 (kernel 2.6.32-279.19.1.v6.i686). Hardware is LinkSys WUSB54G running in AP mode using hostapd, firmware isl3886usb.
Thanks,
Andrew
Jan 29 21:22:27 gateway kernel: ieee80211 phy0: failed to update LEDs (-12).
Jan 29 21:22:27 gateway kernel: ------------[ cut here ]------------
Jan 29 21:22:27 gateway kernel: WARNING: at drivers/net/wireless/p54/main.c:443 p54_work+0x66/0x80 [p54common]() (Not tainted)
Jan 29 21:22:27 gateway kernel: Hardware name:
Jan 29 21:22:27 gateway kernel: Modules linked in: xt_IMQ imq bluetooth aes_i586 aes_generic xt_state nf_nat_h323 nf_conntrack_h323 nf_nat_pptp nf_
nat_proto_gre nf_nat_irc nf_nat_ftp ipt_MASQUERADE nf_conntrack_pptp nf_conntrack_proto_gre ecb ppp_mppe nf_conntrack_irc nf_conntrack_ftp ipt_REJE
CT ipt_LOG iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 iptable_mangle iptable_filter ip_tables ppp_synctty ppp_async ppp_gener
ic slhc bridge stp llc ipv6 ppdev parport_pc parport 8139too 8139cp mii arc4 p54usb p54common crc_ccitt mac80211 cfg80211 rfkill sg snd_intel8x0 snd_ac97_codec ac97_bus snd_seq snd_seq_device snd_pcm snd_timer snd soundcore snd_page_alloc forcedeth i2c_nforce2 ext4 mbcache jbd2 sd_mod crc_t10dif firewire_ohci firewire_core crc_itu_t ata_generic pata_acpi pata_amd nouveau ttm drm_kms_helper drm i2c_core mxm_wmi video output wmi dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan]
Jan 29 21:22:27 gateway kernel: Pid: 678, comm: phy0 Not tainted 2.6.32-279.2.1.v6.i686 #1
Jan 29 21:22:27 gateway kernel: Call Trace:
Jan 29 21:22:27 gateway kernel: [<c0455c11>] ? warn_slowpath_common+0x81/0xc0
Jan 29 21:22:27 gateway kernel: [<f8f569a6>] ? p54_work+0x66/0x80 [p54common]
Jan 29 21:22:27 gateway kernel: [<f8f569a6>] ? p54_work+0x66/0x80 [p54common]
Jan 29 21:22:27 gateway kernel: [<f8f56940>] ? p54_work+0x0/0x80 [p54common]
Jan 29 21:22:27 gateway kernel: [<c0455c6b>] ? warn_slowpath_null+0x1b/0x20
Jan 29 21:22:27 gateway kernel: [<f8f569a6>] ? p54_work+0x66/0x80 [p54common]
Jan 29 21:22:27 gateway kernel: [<c047229b>] ? worker_thread+0x11b/0x230
Jan 29 21:22:27 gateway kernel: [<c0476a10>] ? autoremove_wake_function+0x0/0x40
Jan 29 21:22:27 gateway kernel: [<c0472180>] ? worker_thread+0x0/0x230
Jan 29 21:22:27 gateway kernel: [<c04767d4>] ? kthread+0x74/0x80
Jan 29 21:22:27 gateway kernel: [<c0476760>] ? kthread+0x0/0x80
Jan 29 21:22:27 gateway kernel: [<c0409fff>] ? kernel_thread_helper+0x7/0x10
Jan 29 21:22:27 gateway kernel: ---[ end trace d4e1cfe2fc6a5534 ]---
Jan 29 21:22:30 gateway kernel: ieee80211 phy0: failed to update LEDs (-12).
Jan 29 21:22:34 gateway kernel: ieee80211 phy0: failed to update LEDs (-12).
Jan 29 21:22:37 gateway kernel: ieee80211 phy0: failed to update LEDs (-12).
Jan 29 21:22:45 gateway kernel: ieee80211 phy0: failed to update LEDs (-12).
Jan 29 21:22:45 gateway kernel: ieee80211 phy0: failed to update LEDs (-12).
Jan 29 21:22:45 gateway kernel: ieee80211 phy0: failed to update LEDs (-12).
Jan 29 21:22:46 gateway kernel: ieee80211 phy0: failed to update LEDs (-12).
Hello,
On Wednesday, January 30, 2013 12:04:38 AM Andrew Wasielewski wrote:
> I just had the following crash in p54common.
Yeah, the driver has run out of memory (memory on the device). This
is most likely caused when the firmware "ceased operations". Sadly,
the last available firmware from Conexant for the isl3886 is
2.13.1.0.lm86.arm (and you probably are using it already :-/ )
What's even worse is that neither Conexant nor STE have not and won't
be providing any new images and the freemac project has stalled as well.
The Islsm project had a firmware terminal which could be used to debug
firmware stuff, but it is was never ported.
> The "failed to update LEDs" messages continued until I rebooted - couldn't find
> a way to reload the stack. O/S is ClearOS Community release 6.3.0 (kernel 2.6.32-279.19.1.v6.i686).
> Hardware is LinkSys WUSB54G running in AP mode using hostapd, firmware isl3886usb.
Reloading the driver (modprobe -r p54usb && modprobe p54usb) or replugging the
device should have helped. Anyway, the clean "reset" procedure for these devices
is known but to Conexant. If you have sysfs, you can reset a dead usb device
by toggling (writing 0 and then 1 into) /sys/bus/usb/devices/x-y-z/authorized.
If this helps, we can at least let the driver reset the device automatically
once it bails out. What do you think?
Regards,
Chr
Hi Christian,
On Thursday 07 February 2013 16:57:12 Christian Lamparter wrote:
> Hello Andrew
>
> On Thursday, February 07, 2013 12:51:38 AM Andrew Wasielewski wrote:
> > On Wednesday 30 January 2013 01:06:52 Christian Lamparter wrote:
> > > On Wednesday, January 30, 2013 12:04:38 AM Andrew Wasielewski wrote:
> > > > The "failed to update LEDs" messages continued until I rebooted - couldn't find
> > > > a way to reload the stack. O/S is ClearOS Community release 6.3.0 (kernel 2.6.32-279.19.1.v6.i686).
> > > > Hardware is LinkSys WUSB54G running in AP mode using hostapd, firmware isl3886usb.
> > > Reloading the driver (modprobe -r p54usb && modprobe p54usb) or replugging the
> > > device should have helped. Anyway, the clean "reset" procedure for these devices
> > > is known but to Conexant. If you have sysfs, you can reset a dead usb device
> > > by toggling (writing 0 and then 1 into) /sys/bus/usb/devices/x-y-z/authorized.
> > The "authorized" file doesn't exist in my sysfs
> > > If this helps, we can at least let the driver reset the device automatically
> > > once it bails out. What do you think?
> >
> > modprobing p54usb works with the driver, but I still have to restart hostapd for
> > it to pick up the now-working driver. Good news is it hasn't happened again.
> Ah, you should be able to do this automatically. For example with Debian
> (and Ubuntu?) you can add an entry into your /etc/network/interfaces:
>
> [use tabs]
> allow-hotplug wlan0
> iface wlan0 inet manual
> hostapd /etc/hostapd/hostapd.conf
> up /sbin/ifconfig "$IFACE" 192.168.0.254 netmask 255.255.255.0
I don't have /etc/network/interfaces in ClearOS. Also my wlan0 doesn't have an IP address directly, as it is bridged with wired eth0 in br0. Can that be accomodated?
>
> and it will automatically restart hostapd when the device
> is replugged/driver is reloaded.
> [Note: The driver can detect if the firmware is dead. I'm
> thinking about implementing a simple reset-when-dead feature.
> Would you be willing to test it once it materializes? I'm
> asking because I don't have any isl3886usb. Just the PCI
> versions and two isl3887usb].
Happy to test anything you can offer. Some of us citizens are are with y'all the way officer. However is there any way to trigger / simulate firmware failure, as it doesn't happen very often (fortunately) by itself.
>
> > Unplugging is tricky as I have slightly hacked the WUSB54G to fit inside the case
> > (an old Shuttle mini-PC) with a SMA-RP connector and a decent antenna. In fact the
> > main reason I went for the WUSB54G is because this conversion seemed quite easy.
> > I am open to any suggestions for USB devices with b/g/n(?) support that could be
> > internally mounted in this way, + has AP mode support of course.
> Ah, well the USB + AP requirement is sort of a problem. Usually everyone favourit
> and well-tested WiFi-AP is some sort of a PCI or PCIe solution. But still, there
> are a few alternatives. The most popular are based on:
> - ath9k_htc
> - rt2800usb
>
> Unfortunately, I can't tell if they are adequate for your needs. Some
> people have posted "stability comparision" between those. But I can't
> find any from recent times. Of course, if you are curious and don't mind
> spending 1-10 GBP [per device], you can do your own little experiments
> about cheap USB+AP solutions. I'm sure other people would be interested
> in the results too [that's a hint ;)].
If I come across anything that looks viable I can test it. If I can find a MicroATX M/b that will fit the Shuttle case I will upgrade - ideally one with a PCIe slot for wireless and PCI for the ADSL2+ card. It's a FN41V3 if anyone has any suggestions.
>
> Regards
>
> Christian
Regards,
Andrew
Hello Andrew
On Tuesday, February 12, 2013 01:04:11 AM Andrew Wasielewski wrote:
> On Thursday 07 February 2013 16:57:12 Christian Lamparter wrote:
> > On Thursday, February 07, 2013 12:51:38 AM Andrew Wasielewski wrote:
> > > On Wednesday 30 January 2013 01:06:52 Christian Lamparter wrote:
> > > > On Wednesday, January 30, 2013 12:04:38 AM Andrew Wasielewski wrote:
> > > > Reloading the driver (modprobe -r p54usb && modprobe p54usb) or replugging the
> > > > device should have helped. Anyway, the clean "reset" procedure for these devices
> > > > is known but to Conexant.
> > > modprobing p54usb works with the driver, but I still have to restart hostapd for
> > > it to pick up the now-working driver. Good news is it hasn't happened again.
> > Ah, you should be able to do this automatically. For example with Debian
> > (and Ubuntu?) you can add an entry into your /etc/network/interfaces:
> I don't have /etc/network/interfaces in ClearOS. Also my wlan0 doesn't have
> an IP address directly, as it is bridged with wired eth0 in br0. Can that be
> accomodated?
Do you know how hostapd is started? Is it done automatically, or do you
have some sort of custom initscript?
> > and it will automatically restart hostapd when the device
> > is replugged/driver is reloaded.
> > [Note: The driver can detect if the firmware is dead. I'm
> > thinking about implementing a simple reset-when-dead feature.
> > Would you be willing to test it once it materializes? I'm
> > asking because I don't have any isl3886usb. Just the PCI
> > versions and two isl3887usb].
> Happy to test anything you can offer. However is there any way to trigger /
> simulate firmware failure, as it doesn't happen very often (fortunately) by
> itself.
Sure, crashing the firmware is easy (garbage in, garbage out). But we don't
need to do that, we can simply assume it "crashed" and then test
if the reset code works properly [otherwise it might take all day since
as you said: they happen, but not very often). I'm thinking of taking a
closer looksie this weekend.
> If I come across anything that looks viable I can test it. If I can find a
> MicroATX M/b that will fit the Shuttle case I will upgrade - ideally one with
> a PCIe slot for wireless and PCI for the ADSL2+ card. It's a FN41V3 if
> anyone has any suggestions.
Are you sure a MicroATX M/b fits? It looks like the FN41V3 is a proprietary
form factor. Do you think you can cram a mini-itx inside the case? If you
can, then you could look at a cheap ATOM or BOBCAT mainboard. Some of them
still have a conventional PCI slot and most also do have a minipcie-slot
too (which is preferable since you won't need any pcie<->minipcie adapters)
Regards,
Christian
Hello Andrew
On Thursday, February 07, 2013 12:51:38 AM Andrew Wasielewski wrote:
> On Wednesday 30 January 2013 01:06:52 Christian Lamparter wrote:
> > On Wednesday, January 30, 2013 12:04:38 AM Andrew Wasielewski wrote:
> > > The "failed to update LEDs" messages continued until I rebooted - couldn't find
> > > a way to reload the stack. O/S is ClearOS Community release 6.3.0 (kernel 2.6.32-279.19.1.v6.i686).
> > > Hardware is LinkSys WUSB54G running in AP mode using hostapd, firmware isl3886usb.
> > Reloading the driver (modprobe -r p54usb && modprobe p54usb) or replugging the
> > device should have helped. Anyway, the clean "reset" procedure for these devices
> > is known but to Conexant. If you have sysfs, you can reset a dead usb device
> > by toggling (writing 0 and then 1 into) /sys/bus/usb/devices/x-y-z/authorized.
> The "authorized" file doesn't exist in my sysfs
> > If this helps, we can at least let the driver reset the device automatically
> > once it bails out. What do you think?
>
> modprobing p54usb works with the driver, but I still have to restart hostapd for
> it to pick up the now-working driver. Good news is it hasn't happened again.
Ah, you should be able to do this automatically. For example with Debian
(and Ubuntu?) you can add an entry into your /etc/network/interfaces:
[use tabs]
allow-hotplug wlan0
iface wlan0 inet manual
hostapd /etc/hostapd/hostapd.conf
up /sbin/ifconfig "$IFACE" 192.168.0.254 netmask 255.255.255.0
and it will automatically restart hostapd when the device
is replugged/driver is reloaded.
[Note: The driver can detect if the firmware is dead. I'm
thinking about implementing a simple reset-when-dead feature.
Would you be willing to test it once it materializes? I'm
asking because I don't have any isl3886usb. Just the PCI
versions and two isl3887usb].
> Unplugging is tricky as I have slightly hacked the WUSB54G to fit inside the case
> (an old Shuttle mini-PC) with a SMA-RP connector and a decent antenna. In fact the
> main reason I went for the WUSB54G is because this conversion seemed quite easy.
> I am open to any suggestions for USB devices with b/g/n(?) support that could be
> internally mounted in this way, + has AP mode support of course.
Ah, well the USB + AP requirement is sort of a problem. Usually everyone favourit
and well-tested WiFi-AP is some sort of a PCI or PCIe solution. But still, there
are a few alternatives. The most popular are based on:
- ath9k_htc
- rt2800usb
Unfortunately, I can't tell if they are adequate for your needs. Some
people have posted "stability comparision" between those. But I can't
find any from recent times. Of course, if you are curious and don't mind
spending 1-10 GBP [per device], you can do your own little experiments
about cheap USB+AP solutions. I'm sure other people would be interested
in the results too [that's a hint ;)].
Regards
Christian
Thanks for getting back Christian,
On Wednesday 30 January 2013 01:06:52 Christian Lamparter wrote:
> Hello,
>
> On Wednesday, January 30, 2013 12:04:38 AM Andrew Wasielewski wrote:
> > I just had the following crash in p54common.
> Yeah, the driver has run out of memory (memory on the device). This
> is most likely caused when the firmware "ceased operations". Sadly,
> the last available firmware from Conexant for the isl3886 is
> 2.13.1.0.lm86.arm (and you probably are using it already :-/ )
Yes, that is my version... :-(
> What's even worse is that neither Conexant nor STE have not and won't
> be providing any new images and the freemac project has stalled as well.
> The Islsm project had a firmware terminal which could be used to debug
> firmware stuff, but it is was never ported.
>
> > The "failed to update LEDs" messages continued until I rebooted - couldn't find
> > a way to reload the stack. O/S is ClearOS Community release 6.3.0 (kernel 2.6.32-279.19.1.v6.i686).
> > Hardware is LinkSys WUSB54G running in AP mode using hostapd, firmware isl3886usb.
> Reloading the driver (modprobe -r p54usb && modprobe p54usb) or replugging the
> device should have helped. Anyway, the clean "reset" procedure for these devices
> is known but to Conexant. If you have sysfs, you can reset a dead usb device
> by toggling (writing 0 and then 1 into) /sys/bus/usb/devices/x-y-z/authorized.
The "authorized" file doesn't exist in my sysfs
> If this helps, we can at least let the driver reset the device automatically
> once it bails out. What do you think?
modprobing p54usb works with the driver, but I still have to restart hostapd for it to pick up the now-working driver. Good news is it hasn't happened again. Unplugging is tricky as I have slightly hacked the WUSB54G to fit inside the case (an old Shuttle mini-PC) with a SMA-RP connector and a decent antenna. In fact the main reason I went for the WUSB54G is because this conversion seemed quite easy. I am open to any suggestions for USB devices with b/g/n(?) support that could be internally mounted in this way, + has AP mode support of course.
>
> Regards,
> Chr
Thanks,
Andrew