Re: trigger named just "tx" in drivers/net/wireless/atmel/at76c50x-usb.c
On Mon 2018-12-03 10:45:01, Kalle Valo wrote: > Pavel Machek writes: > > > While grepping something else, I came across LED trigger that is named > > just "tx". > > > > That's a bit too generic afaict? > > > > +++ b/drivers/net/wireless/atmel/at76c50x-usb.c > > @@ -520,7 +520,7 @@ static int at76_usbdfu_download(struct usb_device > > *udev, u8 *buf, u32 size, > > static int tx_activity; > > static void at76_ledtrig_tx_timerfunc(struct timer_list *unused); > >static DEFINE_TIMER(ledtrig_tx_timer, at76_ledtrig_tx_timerfunc); > >-DEFINE_LED_TRIGGER(ledtrig_tx); > >+DEFINE_LED_TRIGGER(ledtrig_tx); /* Hey! "tx" is a bit too generic > >name for a trigger! */ > > This is an ancient driver, my guess is that nobody uses it anymore. I > should orphan it and maybe even remove it at some point. Are you willing to add a fixme there? I really don't want people to copy that example. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
trigger named just "tx" in drivers/net/wireless/atmel/at76c50x-usb.c
Hi! While grepping something else, I came across LED trigger that is named just "tx". That's a bit too generic afaict? +++ b/drivers/net/wireless/atmel/at76c50x-usb.c @@ -520,7 +520,7 @@ static int at76_usbdfu_download(struct usb_device *udev, u8 *buf, u32 size, static int tx_activity; static void at76_ledtrig_tx_timerfunc(struct timer_list *unused); static DEFINE_TIMER(ledtrig_tx_timer, at76_ledtrig_tx_timerfunc); -DEFINE_LED_TRIGGER(ledtrig_tx); +DEFINE_LED_TRIGGER(ledtrig_tx); /* Hey! "tx" is a bit too generic name for a trigger! */ Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH] libertas: don't set URB_ZERO_PACKET on IN USB transfer
On Sat 2018-10-06 22:12:32, Lubomir Rintel wrote:
> The USB core gets rightfully upset:
>
> usb 1-1: BOGUS urb flags, 240 --> 200
> WARNING: CPU: 0 PID: 60 at drivers/usb/core/urb.c:503
> usb_submit_urb+0x2f8/0x3ed
> Modules linked in:
> CPU: 0 PID: 60 Comm: kworker/0:3 Not tainted 4.19.0-rc6-00319-g5206d00a45c7
> #39
> Hardware name: OLPC XO/XO, BIOS OLPC Ver 1.00.01 06/11/2014
> Workqueue: events request_firmware_work_func
> EIP: usb_submit_urb+0x2f8/0x3ed
> Code: 75 06 8b 8f 80 00 00 00 8d 47 78 89 4d e4 89 55 e8 e8 35 1c f6 ff 8b
> 55 e8 56 52 8b 4d e4 51 50 68 e3 ce c7 c0 e8 ed 18 c6 ff <0f> 0b 83 c4 14 80
> 7d ef 01 74 0a 80 7d ef 03 0f 85 b8 00 00 00 8b
> EAX: 0025 EBX: ce7d4980 ECX: EDX: 0001
> ESI: 0200 EDI: ce7d8800 EBP: ce7f5ea8 ESP: ce7f5e70
> DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 EFLAGS: 00210292
> CR0: 80050033 CR2: CR3: 00e8 CR4: 0090
> Call Trace:
>? if_usb_fw_timeo+0x64/0x64
>__if_usb_submit_rx_urb+0x85/0xe6
>? if_usb_fw_timeo+0x64/0x64
>if_usb_submit_rx_urb_fwload+0xd/0xf
>if_usb_prog_firmware+0xc0/0x3db
>? _request_firmware+0x54/0x47b
>? _request_firmware+0x89/0x47b
>? if_usb_probe+0x412/0x412
>lbs_fw_loaded+0x55/0xa6
>? debug_smp_processor_id+0x12/0x14
>helper_firmware_cb+0x3c/0x3f
>request_firmware_work_func+0x37/0x6f
>process_one_work+0x164/0x25a
>worker_thread+0x1c4/0x284
>kthread+0xec/0xf1
>? cancel_delayed_work_sync+0xf/0xf
>? kthread_create_on_node+0x1a/0x1a
>ret_from_fork+0x2e/0x38
> ---[ end trace 3ef1e3b2dd53852f ]---
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Lubomir Rintel
Acked-by: Pavel Machek
> ---
> drivers/net/wireless/marvell/libertas/if_usb.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/net/wireless/marvell/libertas/if_usb.c
> b/drivers/net/wireless/marvell/libertas/if_usb.c
> index 5fee555a3d60..220dcdee8d2b 100644
> --- a/drivers/net/wireless/marvell/libertas/if_usb.c
> +++ b/drivers/net/wireless/marvell/libertas/if_usb.c
> @@ -459,8 +459,6 @@ static int __if_usb_submit_rx_urb(struct if_usb_card
> *cardp,
> MRVDRV_ETH_RX_PACKET_BUFFER_SIZE, callbackfn,
> cardp);
>
> - cardp->rx_urb->transfer_flags |= URB_ZERO_PACKET;
> -
> lbs_deb_usb2(&cardp->udev->dev, "Pointer for rx_urb %p\n",
> cardp->rx_urb);
> if ((ret = usb_submit_urb(cardp->rx_urb, GFP_ATOMIC))) {
> lbs_deb_usbd(&cardp->udev->dev, "Submit Rx URB failed: %d\n",
> ret);
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH v2] libertas: return errno from lbs_add_card()
On Sun 2018-10-07 02:33:27, Lubomir Rintel wrote: > This makes the error handling somewhat cleaner -- lbs_add_card() does no > logner throw away the errno and lets its callers propagate it. > > Signed-off-by: Lubomir Rintel Acked-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets
Hi! > show me a proof that its copy & paste. because its not I don't have to prove you anything. Sorry. But you said: > >>see ath9k. its exact the same implementation. We don't want to have exact same code multiple times in the tree. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets
On Thu 2018-03-08 13:33:29, Sebastian Gottschall wrote:
> Am 08.03.2018 um 10:02 schrieb Pavel Machek:
> >On Wed 2018-03-07 18:54:41, Sebastian Gottschall wrote:
> >>Am 07.03.2018 um 17:22 schrieb Rafał Miłecki:
> >>>On 2 March 2018 at 10:22, Sebastian Gottschall
> >>>wrote:
> >>>>>>leds-gpio is crap and limited. you can just register one platform data
> >>>>>>at
> >>>>>>kernel runtime since its identified by its object name "led-gpio" but
> >>>>>>the
> >>>>>>kernel forbidds to register 2 platform datas with the same name
> >>>>>>consider the ar71xx devices with qca988x wifi chipsets. they all have
> >>>>>>already a led platform data registered
> >>>>>>at boottime. a second can't be registered anymore so gpio_led is useless
> >>>>>>at
> >>>>>>all for most developers on such platforms. its mainly used for early
> >>>>>>kernel
> >>>>>>platform data initialisation for system leds.
> >>>>>If leds-gpio has limitations, please fix those, rather then
> >>>>>introducing duplicated code.
> >>>>there is no duplicated code introduced and there is no solution for it.
> >>>>consider that all wifi drivers with softled support
> >>>>are going that way with registering a own led driver. see ath9k for
> >>>>instance. gpio-led cannot be used for it and there is no way to
> >>>>support multiple platform datas with the same name. its a kernel
> >>>>limitation
> >>>I just reviewed some mips arch patch adding support for more LEDs for
> >>>selected devices:
> >>>[PATCH] MIPS: BCM47XX: Add Luxul XAP1500/XWR1750 WiFi LEDs
> >>>https://patchwork.linux-mips.org/patch/18681/
> >>>
> >>>It seems to be simply adding another call to the
> >>>gpio_led_register_device(). It seems to me you can call that function
> >>>multiple times and register multiple structs with LEDs.
> >>>
> >>>Isn't all you need something like this?
> >>>
> >>>static const struct gpio_led ath10k_leds[] = {
> >>> {
> >>> .name = "ath10k:color:function",
> >>> .active_low = 1,
> >>> .default_state = LEDS_GPIO_DEFSTATE_KEEP,
> >>> }
> >>>};
> >>>
> >>>static struct gpio_led_platform_data bcm47xx_leds_pdata_extra = {
> >>> leds = ath10k_leds;
> >>> num_leds = ARRAY_SIZE(ath10k_leds);
> >>>};
> >>>
> >>>ath10k_leds.gpio = ar->hw_params.led_pin;
> >>>gpio_led_register_device(0, &ath10k_leds);
> >>the problem are other architectures which have already registered gpio_led
> >>at system start like ar71xx
> >>you cannot register a second one. so a independend led driver is a
> >>requirement for direct control
> >If the limitation indeed exists, please fix the limitation rather than
> >working around it in each and every driver.
> see ath9k. its exact the same implementation.
Ok, so one more driver to fix.
> in addition my variant does also work without gpiolib support. so it can be
> used even if the kernel is configured
> without gpio support.
> and not to forget, using a own led driver is more ligthweight from the call
> path for each led on / off event which is important for
> low performance embedded devices
We are not going to copy&paste code because such code works without
libraries, and we are not going to copy&paste code because that uses
less cache during calls. Sorry.
NAK. Please fix your patch.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets
On Wed 2018-03-07 18:54:41, Sebastian Gottschall wrote:
> Am 07.03.2018 um 17:22 schrieb Rafał Miłecki:
> >On 2 March 2018 at 10:22, Sebastian Gottschall
> >wrote:
> leds-gpio is crap and limited. you can just register one platform data at
> kernel runtime since its identified by its object name "led-gpio" but the
> kernel forbidds to register 2 platform datas with the same name
> consider the ar71xx devices with qca988x wifi chipsets. they all have
> already a led platform data registered
> at boottime. a second can't be registered anymore so gpio_led is useless
> at
> all for most developers on such platforms. its mainly used for early
> kernel
> platform data initialisation for system leds.
> >>>If leds-gpio has limitations, please fix those, rather then
> >>>introducing duplicated code.
> >>there is no duplicated code introduced and there is no solution for it.
> >>consider that all wifi drivers with softled support
> >>are going that way with registering a own led driver. see ath9k for
> >>instance. gpio-led cannot be used for it and there is no way to
> >>support multiple platform datas with the same name. its a kernel limitation
> >I just reviewed some mips arch patch adding support for more LEDs for
> >selected devices:
> >[PATCH] MIPS: BCM47XX: Add Luxul XAP1500/XWR1750 WiFi LEDs
> >https://patchwork.linux-mips.org/patch/18681/
> >
> >It seems to be simply adding another call to the
> >gpio_led_register_device(). It seems to me you can call that function
> >multiple times and register multiple structs with LEDs.
> >
> >Isn't all you need something like this?
> >
> >static const struct gpio_led ath10k_leds[] = {
> > {
> > .name = "ath10k:color:function",
> > .active_low = 1,
> > .default_state = LEDS_GPIO_DEFSTATE_KEEP,
> > }
> >};
> >
> >static struct gpio_led_platform_data bcm47xx_leds_pdata_extra = {
> > leds = ath10k_leds;
> > num_leds = ARRAY_SIZE(ath10k_leds);
> >};
> >
> >ath10k_leds.gpio = ar->hw_params.led_pin;
> >gpio_led_register_device(0, &ath10k_leds);
> the problem are other architectures which have already registered gpio_led
> at system start like ar71xx
> you cannot register a second one. so a independend led driver is a
> requirement for direct control
If the limitation indeed exists, please fix the limitation rather than
working around it in each and every driver.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets
Hi! > >>adds also debugfs interface for gpio control. > >Hi Sebastian, > > > >I just noticed this patch and have one question. It seems you register > >GPIO chip and that WiFi LED is controller by a GPIO. Shouldn't you use > >leds-gpio driver and just register platform device with > >gpio_led_platform_data? That way you could avoid some code duplication > >I think? It seems to be the purpose of leds-gpio driver. > leds-gpio is crap and limited. you can just register one platform data at > kernel runtime since its identified by its object name "led-gpio" but the > kernel forbidds to register 2 platform datas with the same name > consider the ar71xx devices with qca988x wifi chipsets. they all have > already a led platform data registered > at boottime. a second can't be registered anymore so gpio_led is useless at > all for most developers on such platforms. its mainly used for early kernel > platform data initialisation for system leds. If leds-gpio has limitations, please fix those, rather then introducing duplicated code. NAK. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
4.15-rc5 was ath5k: WARN_ON in ieee80211_rx_napi()
Hi! I'm getting WARN_ON() on heavy wifi use, thinkpad T40p... Any ideas? BTW can we get rid of the ath5k: ath5k_hw_get_isr: ISR: 0x0080 IMR: 0x80081035 debugging print? Thanks, Pavel [0.00] Linux version 4.15.0-rc5autobisect1514286372+ (pavel@duo) (gcc version 4.9.2 (Debian 4.9.2-10)) #493 SMP Tue Dec 26 12:06:29 CET 2017 [0.00] x86/fpu: x87 FPU will use FXSAVE .. [0.802875] CSLIP: code copyright 1989 Regents of the University of California. [0.803844] ath5k :02:02.0: registered as 'phy0' [0.960567] ata2.00: ATAPI: UJDA765 DVD/CDRW, 1.70, max UDMA/33 [0.961465] ata1.00: ATA-7: SAMSUNG MP0402H, UC200-16, max UDMA/100 ... [1.095641] sr 1:0:0:0: Attached scsi generic sg1 type 5 [1.472208] clocksource: tsc: mask: 0x max_cycles: 0x170ac2bcf87, max_idle_ns: 440795227634 ns [4.956138] ath: EEPROM regdomain: 0x61 [4.956142] ath: EEPROM indicates we should expect a direct regpair map [4.956148] ath: Country alpha2 being used: 00 [4.956151] ath: Regpair used: 0x61 [4.956769] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' [4.958141] ath5k: phy0: Atheros AR5211 chip found (MAC: 0x42, PHY: 0x30) [4.969935] ath5k: phy0: RF5111 5GHz radio found (0x17) [4.981728] ath5k: phy0: RF2111 2GHz radio found (0x23) [4.993632] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, in-tree:ds ...[ 30.540578] systemd-journald[2185]: Received request to flush runtime journal from PID 1 [ 39.654431] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory [ 39.687498] NFSD: starting 90-second grace period (net f099) [ 62.825074] ath5k: ath5k_hw_get_isr: ISR: 0x0400 IMR: 0x80081035 [ 66.904118] wlan1: authenticate with 00:33:13:01:31:45 [ 66.941152] wlan1: send auth to 00:33:13:01:31:45 (try 1/3) [ 66.942793] wlan1: authenticated [ 66.948493] wlan1: associate with 00:33:13:01:31:45 (try 1/3) [ 66.950754] wlan1: RX AssocResp from 00:33:13:01:31:45 (capab=0x1 status=0 aid=7) [ 66.951133] wlan1: associated [ 88.984630] ath5k: ath5k_hw_get_isr: ISR: 0x0080 IMR: 0x80081035 [ 119.009541] ath5k: ath5k_hw_get_isr: ISR: 0x0080 IMR: 0x80081035 ... [ 725.530201] WARNING: CPU: 0 PID: 0 at net/mac80211/rx.c:629 ieee80211_rx_napi+0x8b0/0x9d0 [ 725.530221] Modules linked in: [ 725.530248] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.15.0-rc5autobisect1514286372+ #493 [ 725.530261] Hardware name: IBM 2373G3U/2373G3U, BIOS 1RETDNWW (3.19 ) 10/13/2005 [ 725.530279] EIP: ieee80211_rx_napi+0x8b0/0x9d0 [ 725.530292] EFLAGS: 00210246 CPU: 0 [ 725.530306] EAX: 0004 EBX: ECX: 0001 EDX: [ 725.530320] ESI: f0167780 EDI: EBP: f680ff68 ESP: f680ff00 [ 725.530334] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 725.530348] CR0: 80050033 CR2: 080c5fb0 CR3: 35a45ca0 CR4: 06b0 [ 725.530361] Call Trace: [ 725.530376] [ 725.530398] ? __build_skb+0x21/0xd0 [ 725.530417] ? nommu_map_page+0x47/0x80 [ 725.530439] ? ath5k_rx_skb_alloc+0x6c/0x140 [ 725.530455] ath5k_tasklet_rx+0x2b8/0x660 [ 725.530475] tasklet_action+0x8e/0xa0 [ 725.530494] __do_softirq+0xcf/0x1a8 [ 725.530511] ? __irqentry_text_end+0x7/0x7 [ 725.530529] do_softirq_own_stack+0x1d/0x30 [ 725.530542] [ 725.530557] irq_exit+0x87/0xa0 [ 725.530572] do_IRQ+0x40/0xb0 [ 725.530589] common_interrupt+0x38/0x40 [ 725.530605] EIP: cpuidle_enter_state+0xa4/0x220 [ 725.530618] EFLAGS: 00200282 CPU: 0 [ 725.530632] EAX: ecf4d461 EBX: ecf4d461 ECX: ecf4d2b8 EDX: f6df2540 [ 725.530646] ESI: 00a8 EDI: 0002 EBP: c4fc3f20 ESP: c4fc3f04 [ 725.530660] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 725.530678] cpuidle_enter+0xf/0x20 [ 725.530698] call_cpuidle+0x23/0x40 [ 725.530714] do_idle+0x174/0x1b0 [ 725.530730] cpu_startup_entry+0x55/0x60 [ 725.530748] rest_init+0xef/0x100 [ 725.530767] start_kernel+0x31e/0x325 [ 725.530783] i386_start_kernel+0x8a/0x8e [ 725.530798] startup_32_smp+0x164/0x168 [ 725.530812] Code: ff 8d 76 00 8d bc 27 00 00 00 00 89 f7 8b 75 98 e9 30 ff ff ff 8d b6 00 00 00 00 c6 45 a3 00 e9 ff fa ff ff 8d b4 26 00 00 00 00 <0f> ff 89 f0 e8 97 30 e6 ff e9 b6 fa ff ff 66 90 0f ff e9 71 fa [ 725.531328] ---[ end trace fd7bd3f8fba6af4c ]--- [ 725.531418] WARNING: CPU: 0 PID: 0 at net/mac80211/rx.c:629 ieee80211_rx_napi+0x8b0/0x9d0 [ 725.531429] Modules linked in: [ 725.531454] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW 4.15.0-rc5autobisect1514286372+ #493 [ 725.531467] Hardware name: IBM 2373G3U/2373G3U, BIOS 1RETDNWW (3.19 ) 10/13/2005 [ 725.531482] EIP: ieee80211_rx_napi+0x8b0/0x9d0 [ 725.531495] EFLAGS: 00210246 CPU: 0 [ 725.531508] EAX: 0004 EBX: ECX: 0001 EDX: [ 725.531522] ESI: f3a23600 EDI: EBP: f680ff68 ESP: f680ff00 [ 725.531536] DS: 007b ES: 007b FS: 00d8 GS:
Re: [PATCH] wl1251: check return from call to wl1251_acx_arp_ip_filter
On Tue 2017-12-26 17:33:18, Colin King wrote:
> From: Colin Ian King
>
> Currently the less than zero error check on ret is incorrect
> as it is checking a far earlier ret assignment rather than the
> return from the call to wl1251_acx_arp_ip_filter. Fix this by
> adding in the missing assginment.
>
> Detected by CoverityScan, CID#1164835 ("Logically dead code")
>
> Fixes: 204cc5c44fb6 ("wl1251: implement hardware ARP filtering")
> Signed-off-by: Colin Ian King
Hmm. So yes, it might be correct. OTOH, this change may also break
something. So... how was it tested?
Pavel
> ---
> drivers/net/wireless/ti/wl1251/main.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ti/wl1251/main.c
> b/drivers/net/wireless/ti/wl1251/main.c
> index 6d02c660b4ab..037defd10b91 100644
> --- a/drivers/net/wireless/ti/wl1251/main.c
> +++ b/drivers/net/wireless/ti/wl1251/main.c
> @@ -1200,8 +1200,7 @@ static void wl1251_op_bss_info_changed(struct
> ieee80211_hw *hw,
> WARN_ON(wl->bss_type != BSS_TYPE_STA_BSS);
>
> enable = bss_conf->arp_addr_cnt == 1 && bss_conf->assoc;
> - wl1251_acx_arp_ip_filter(wl, enable, addr);
> -
> + ret = wl1251_acx_arp_ip_filter(wl, enable, addr);
> if (ret < 0)
> goto out_sleep;
> }
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH] mac80211: fix locking in ieee80211_sta_tear_down_BA_sessions
On Sat 2017-12-09 21:13:38, Johannes Berg wrote:
> From: Johannes Berg
>
> Due to overlap between
> commit 1281103770e9 ("mac80211: Simplify locking in
> ieee80211_sta_tear_down_BA_sessions()")
> and the way that Luca modified
> commit 72e2c3438ba3 ("mac80211: tear down RX aggregations first")
> when sending it upstream from Intel's internal tree, we get
> the following warning:
>
> WARNING: CPU: 0 PID: 5472 at net/mac80211/agg-tx.c:315
> ___ieee80211_stop_tx_ba_session+0x158/0x1f0
>
> since there's no appropriate locking around the call to
> ___ieee80211_stop_tx_ba_session; Sara's original just had
> a call to the locked __ieee80211_stop_tx_ba_session (one
> less underscore) but it looks like Luca modified both of
> the calls when fixing it up for upstream, leading to the
> problem at hand.
>
> Move the locking appropriately to fix this problem.
>
> Reported-by: Kalle Valo
> Reported-by: Pavel Machek
> Signed-off-by: Johannes Berg
Tested-by: Pavel Machek
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
iwl3945: regression at 4.15-rc1 was Re: 4.15.0-rc1-next-20171201: WARNING: .... at net/mac80211/agg-tx.c:315
Hi! > > This is quite annoying: repeated > > > > [ 4169.591529] ---[ end trace e65d97cf1d20b84d ]--- > > [ 4169.591565] WARNING: CPU: 0 PID: 5472 at net/mac80211/agg-tx.c:315 > > ___ieee80211_stop_tx_\ > > ba_session+0x158/0x1f0 > > > > Hardware is thinkpad x60. Git blame says cfcdbde35 introduced the > > test. > > To save time for others, the driver is iwl3945: > > > [0.970687] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection > > driver for Linux, in-tree:ds > > [0.970690] iwl3945: Copyright(c) 2003-2011 Intel Corporation > > [0.970692] iwl3945: hw_scan is disabled > > [0.971082] iwl3945 :03:00.0: can't disable ASPM; OS doesn't have > > ASPM control > > [1.026281] iwl3945 :03:00.0: Tunable channels: 11 802.11bg, 13 > > 802.11a channels > > [1.026287] iwl3945 :03:00.0: Detected Intel Wireless WiFi Link > > 3945ABG > > [1.027866] ieee80211 phy0: Selected rate control algorithm 'iwl-3945-rs' And same problem is there in 4.15-rc1. It is regression from 4.14. [ 530.816390] WARNING: CPU: 1 PID: 3193 at net/mac80211/agg-tx.c:315 ___ieee802 11_stop_tx_ba_session+0x158/0x1f0 [ 530.816395] Modules linked in: [ 530.816405] CPU: 1 PID: 3193 Comm: wpa_supplicant Tainted: G W 4.15.0-rc1+ #447 [ 530.816410] Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW (2.19 ) 03/3 1/2011 [ 530.816416] task: 17453748 task.stack: 79a41831 [ 530.816422] EIP: ___ieee80211_stop_tx_ba_session+0x158/0x1f0 [ 530.816427] EFLAGS: 00010246 CPU: 1 [ 530.816433] EAX: EBX: f5c19000 ECX: f5eff670 EDX: f5eff040 [ 530.816438] ESI: 000f EDI: 0003 EBP: ef32dbb4 ESP: ef32db8c [ 530.816444] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 530.816450] CR0: 80050033 CR2: 091a4008 CR3: 34d412c0 CR4: 06b0 [ 530.816455] Call Trace: [ 530.816463] ieee80211_sta_tear_down_BA_sessions+0x6e/0xd0 [ 530.816470] __sta_info_destroy_part1+0x3d/0x1f0 -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
4.15.0-rc1-next-20171201: WARNING: .... at net/mac80211/agg-tx.c:315
Hi! This is quite annoying: repeated [ 4169.591529] ---[ end trace e65d97cf1d20b84d ]--- [ 4169.591565] WARNING: CPU: 0 PID: 5472 at net/mac80211/agg-tx.c:315 ___ieee80211_stop_tx_\ ba_session+0x158/0x1f0 Hardware is thinkpad x60. Git blame says cfcdbde35 introduced the test. Pavel [0.00] Linux version 4.15.0-rc1-next-20171201 (pavel@amd) (gcc version 4.9.2 (Debian 4.9.2-10)) #4 SMP Sat Dec 2 11:25:11 CET 2017 [0.00] Disabled fast string operations [0.00] x86/fpu: x87 FPU will use FXSAVE [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009efff] usable [0.00] BIOS-e820: [mem 0x0009f000-0x0009] reserved [0.00] BIOS-e820: [mem 0x000dc000-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xbf6c] usable [0.00] BIOS-e820: [mem 0xbf6d-0xbf6defff] ACPI data [0.00] BIOS-e820: [mem 0xbf6df000-0xbf6f] ACPI NVS [0.00] BIOS-e820: [mem 0xbf70-0xbfff] reserved [0.00] BIOS-e820: [mem 0xf000-0xf3ff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec0] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed003ff] reserved [0.00] BIOS-e820: [mem 0xfed14000-0xfed19fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed8] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xff80-0x] reserved [0.00] NX (Execute Disable) protection: active [0.00] random: fast init done [0.00] SMBIOS 2.4 present. [0.00] DMI: LENOVO 17097HU/17097HU, BIOS 7BETD8WW (2.19 ) 03/31/2011 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0xbf6d0 max_arch_pfn = 0x100 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-C write-protect [0.00] D-DBFFF uncachable [0.00] DC000-D write-back [0.00] E-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0 mask F8000 write-back [0.00] 1 base 08000 mask FC000 write-back [0.00] 2 base 0BF70 mask 0 uncachable [0.00] 3 base 0BF80 mask FFF80 uncachable [0.00] 4 disabled [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] x86/PAT: PAT not supported by CPU. [0.00] x86/PAT: Configuration [0-7]: WB WT UC- UC WB WT UC- UC [0.00] initial memory mapped: [mem 0x-0x05df] [0.00] Base memory trampoline at [(ptrval)] 9b000 size 16384 [0.00] BRK [0x0591a000, 0x0591afff] PGTABLE [0.00] BRK [0x0591b000, 0x0591bfff] PGTABLE [0.00] ACPI: Early table checksum verification disabled [0.00] ACPI: RSDP 0x000F67C0 24 (v02 LENOVO) [0.00] ACPI: XSDT 0xBF6D191C 84 (v01 LENOVO TP-7B 2190 LTP ) [0.00] ACPI: FACP 0xBF6D1A00 F4 (v03 LENOVO TP-7B 2190 LNVO 0001) [0.00] ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block: 64/32 (20171110/tbfadt-603) [0.00] ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has valid Address but zero Length: 0x102C/0x0 (20171110/tbfadt-658) [0.00] ACPI: DSDT 0xBF6D1D90 00CFB9 (v01 LENOVO TP-7B 2190 MSFT 010E) [0.00] ACPI: FACS 0xBF6F4000 40 [0.00] ACPI: FACS 0xBF6F4000 40 [0.00] ACPI: SSDT 0xBF6D1BB4 0001DC (v01 LENOVO TP-7B 2190 MSFT 010E) [0.00] ACPI: ECDT 0xBF6DED49 52 (v01 LENOVO TP-7B 2190 LNVO 0001) [0.00] ACPI: TCPA 0xBF6DED9B 32 (v02 LENOVO TP-7B 2190 LNVO 0001) [0.00] ACPI: APIC 0xBF6DEDCD 68 (v01 LENOVO TP-7B 2190 LNVO 0001) [0.00] ACPI: MCFG 0xBF6DEE35 3C (v01 LENOVO TP-7B 2190 LNVO 0001) [0.00] ACPI: HPET 0xBF6DEE71 38 (v01 LENOVO TP-7B 2190 LNVO 0001) [0.00] ACPI: BOOT 0xBF6DEFD8 28 (v01 LENOVO TP-7B 2190 LTP 0001) [0.00] ACPI: SSDT 0xBF6F2645 00025F (v01 LENOVO TP-7B 2190 INTL 20050513) [0.00] ACPI: SSDT 0xBF6F28A4 A6 (v01 LENOVO TP-7B 2190 INTL 20050513
Re: rc2-next-20170929: wireless down, won't come up
On Mon 2017-10-16 12:51:55, Stanislaw Gruszka wrote: > Hi > > Site note: Intel folks do not support iwlegacy, I removed them from CC. > > On Mon, Oct 16, 2017 at 12:27:45PM +0200, Pavel Machek wrote: > > > In -next... after few days of usage with suspend and resume cycles, > > > wifi failed on thinkpad x60. I have not seen this in years... > > > > Any ideas? > > We do not have any recent iwlegacy changes except cosmetic > ones, so this problem most likely is mac80211, pci or other > subsystem issue > > > Suspend+resume fixed the problem. > > It is not reproducible? If so, I think it will not be > easy to identify the issue. So far it happened once... so I don't know about reproducibility. And I'm not even sure if I'm using iwlegacy driver. Am I? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: rc2-next-20170929: wireless down, won't come up
Hi! > In -next... after few days of usage with suspend and resume cycles, > wifi failed on thinkpad x60. I have not seen this in years... > > [28140.944044] CE: hpet increased min_delta_ns to 20115 nsec > [28174.048418] iwl3945 :03:00.0: Error sending C_RATE_SCALE: time > out after 500ms. > [28174.048430] iwl3945 :03:00.0: Error setting HW rate table: > FF92 > [28174.186576] iwl3945 :03:00.0: Error: Response NULL in > 'C_ADD_STA' > [28174.186593] iwl3945 :03:00.0: Adding station 00:00:00:00:00:01 > failed. > [28174.206312] iwl3945 :03:00.0: Error: Response NULL in > 'C_ADD_STA' > [28174.206326] iwl3945 :03:00.0: Adding station ff:ff:ff:ff:ff:ff > failed. > [30306.599241] wlan0: deauthenticating from 00:00:00:00:00:01 by local > choice (Reason: 3=DEAUTH_LEAVING) > [30306.624302] iwl3945 :03:00.0: Error removing station > 00:00:00:00:00:01 > [30309.055257] wlan0: authenticate with 00:00:00:00:00:01 > [30309.055631] wlan0: send auth to 00:00:00:00:00:01 (try 1/3) > [30309.256142] wlan0: send auth to 00:00:00:00:00:01 (try 2/3) > [30309.460114] wlan0: send auth to 00:00:00:00:00:01 (try 3/3) > [30309.664117] wlan0: authentication with 00:00:00:00:00:01 timed out > > (Yes, my AP has funny hw address; but its other hw address fails, too). > > Any ideas? Suspend+resume fixed the problem. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
rc2-next-20170929: wireless down, won't come up
Hi! In -next... after few days of usage with suspend and resume cycles, wifi failed on thinkpad x60. I have not seen this in years... [28140.944044] CE: hpet increased min_delta_ns to 20115 nsec [28174.048418] iwl3945 :03:00.0: Error sending C_RATE_SCALE: time out after 500ms. [28174.048430] iwl3945 :03:00.0: Error setting HW rate table: FF92 [28174.186576] iwl3945 :03:00.0: Error: Response NULL in 'C_ADD_STA' [28174.186593] iwl3945 :03:00.0: Adding station 00:00:00:00:00:01 failed. [28174.206312] iwl3945 :03:00.0: Error: Response NULL in 'C_ADD_STA' [28174.206326] iwl3945 :03:00.0: Adding station ff:ff:ff:ff:ff:ff failed. [30306.599241] wlan0: deauthenticating from 00:00:00:00:00:01 by local choice (Reason: 3=DEAUTH_LEAVING) [30306.624302] iwl3945 :03:00.0: Error removing station 00:00:00:00:00:01 [30309.055257] wlan0: authenticate with 00:00:00:00:00:01 [30309.055631] wlan0: send auth to 00:00:00:00:00:01 (try 1/3) [30309.256142] wlan0: send auth to 00:00:00:00:00:01 (try 2/3) [30309.460114] wlan0: send auth to 00:00:00:00:00:01 (try 3/3) [30309.664117] wlan0: authentication with 00:00:00:00:00:01 timed out (Yes, my AP has funny hw address; but its other hw address fails, too). Any ideas? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH] wl1251: add a missing spin_lock_init()
Hi! On Thu 2017-08-31 12:26:45, David Miller wrote: > From: Pavel Machek > Date: Thu, 31 Aug 2017 20:57:19 +0200 > > > Hi! > > > >> From: Pavel Machek > >> Date: Thu, 31 Aug 2017 16:47:43 +0200 > >> > >> > Dave, Linus -- can you still take the patch? > >> > >> Pavel, please do not bypass maintainers like this. > >> > >> It's really rude, and if you do things like that instead of > >> trying to work properly with us, your relationship with > >> these maintainers will suffer in the long term. > > > > Do you mean I'm being rude to Kalle, or rude to you? > > He said "to David", not "David and Linus". Ok. If I knew you would be replying so quickly, I'd acted differently. I did not want to be rude. But I'd still like to get the patch in. Do you plan to send another pull request to Linus, and can you take the patch, please? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH] wl1251: add a missing spin_lock_init()
Hi! > From: Pavel Machek > Date: Thu, 31 Aug 2017 16:47:43 +0200 > > > Dave, Linus -- can you still take the patch? > > Pavel, please do not bypass maintainers like this. > > It's really rude, and if you do things like that instead of > trying to work properly with us, your relationship with > these maintainers will suffer in the long term. Do you mean I'm being rude to Kalle, or rude to you? In the part you snipped, Kalle asked me to do just that: # I'm not planning to submit pull requests to 4.13 anymore. If you think # this is so important that it needs to be applied in the last minute (I # don't) you could always try to convince Dave to take it directly. ..and as I still believe patch should go in, that's what I did. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
[PATCH] wl1251: add a missing spin_lock_init()
From: Cong Wang wl1251: add a missing spin_lock_init() This fixes the following kernel warning: [ 5668.771453] BUG: spinlock bad magic on CPU#0, kworker/u2:3/9745 [ 5668.771850] lock: 0xce63ef20, .magic: , .owner: /-1, .owner_cpu: 0 [ 5668.772277] CPU: 0 PID: 9745 Comm: kworker/u2:3 Tainted: GW 4.12.0-03002-gec979a4-dirty #40 [ 5668.772796] Hardware name: Nokia RX-51 board [ 5668.773071] Workqueue: phy1 wl1251_irq_work [ 5668.773345] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 5668.773803] [] (show_stack) from [] (do_raw_spin_lock+0x6c/0xa0) [ 5668.774230] [] (do_raw_spin_lock) from [] (_raw_spin_lock_irqsave+0x10/0x18) [ 5668.774658] [] (_raw_spin_lock_irqsave) from [] (wl1251_op_tx+0x38/0x5c) [ 5668.775115] [] (wl1251_op_tx) from [] (ieee80211_tx_frags+0x188/0x1c0) [ 5668.775543] [] (ieee80211_tx_frags) from [] (__ieee80211_tx+0x6c/0x130) [ 5668.775970] [] (__ieee80211_tx) from [] (ieee80211_tx+0xdc/0x104) [ 5668.776367] [] (ieee80211_tx) from [] (__ieee80211_subif_start_xmit+0x454/0x8c8) [ 5668.776824] [] (__ieee80211_subif_start_xmit) from [] (ieee80211_subif_start_xmit+0x30/0x2fc) [ 5668.777343] [] (ieee80211_subif_start_xmit) from [] (dev_hard_start_xmit+0x80/0x118) ... by adding the missing spin_lock_init(). Reported-by: Pavel Machek Cc: Kalle Valo Signed-off-by: Cong Wang Acked-by: Pavel Machek Signed-off-by: Kalle Valo Signed-off-by: Pavel Machek Cc: sta...@kernel.org --- > >> Yeah, you are right there. I did actually ponder which I tree should > >> commit it back in July but due to various reasons decided differently. > > > > Can we still get the fix to v4.13-final? :-). > > I'm not planning to submit pull requests to 4.13 anymore. If you think > this is so important that it needs to be applied in the last minute (I > don't) you could always try to convince Dave to take it directly. > > Or better yet, push it to the stable tree. If the merge window opens on > Sunday I suspect that the commit will be in Linus' tree sometime next > week. Then you can submit the request to the stable team to take it. I don't think we should use stable tree as an excuse for not fixing the bugs in mainline. Original patch is from Jul 6, thats 7 weeks ago. Dave, Linus -- can you still take the patch? Thanks, Pavel diff --git a/drivers/net/wireless/ti/wl1251/main.c b/drivers/net/wireless/ti/wl1251/main.c index 08f0477..9915d83 100644 --- a/drivers/net/wireless/ti/wl1251/main.c +++ b/drivers/net/wireless/ti/wl1251/main.c @@ -1571,6 +1571,7 @@ struct ieee80211_hw *wl1251_alloc_hw(void) wl->state = WL1251_STATE_OFF; mutex_init(&wl->mutex); + spin_lock_init(&wl->wl_lock); wl->tx_mgmt_frm_rate = DEFAULT_HW_GEN_TX_RATE; wl->tx_mgmt_frm_mod = DEFAULT_HW_GEN_MODULATION_TYPE; -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [Patch net] wl1251: add a missing spin_lock_init()
Hi! On Thu 2017-07-06 15:00:37, Cong Wang wrote: > This fixes the following kernel warning: > > [ 5668.771453] BUG: spinlock bad magic on CPU#0, kworker/u2:3/9745 > [ 5668.771850] lock: 0xce63ef20, .magic: , .owner: /-1, > .owner_cpu: 0 ... > by adding the missing spin_lock_init(). > > Reported-by: Pavel Machek > Cc: Kalle Valo > Signed-off-by: Cong Wang Ping? This is pretty trivial bugfix for an ugly problem. It would be nice to take it in. > drivers/net/wireless/ti/wl1251/main.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/net/wireless/ti/wl1251/main.c > b/drivers/net/wireless/ti/wl1251/main.c > index bbf7604..1c539c8 100644 > --- a/drivers/net/wireless/ti/wl1251/main.c > +++ b/drivers/net/wireless/ti/wl1251/main.c > @@ -1571,6 +1571,7 @@ struct ieee80211_hw *wl1251_alloc_hw(void) > > wl->state = WL1251_STATE_OFF; > mutex_init(&wl->mutex); > + spin_lock_init(&wl->wl_lock); > > wl->tx_mgmt_frm_rate = DEFAULT_HW_GEN_TX_RATE; > wl->tx_mgmt_frm_mod = DEFAULT_HW_GEN_MODULATION_TYPE; -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [Patch net] wl1251: add a missing spin_lock_init()
Hi! > This fixes the following kernel warning: > > [ 5668.771453] BUG: spinlock bad magic on CPU#0, kworker/u2:3/9745 ... > [ 5668.777343] [] (ieee80211_subif_start_xmit) from > [] (dev_hard_start_xmit+0x80/0x118) > ... > > by adding the missing spin_lock_init(). > > Reported-by: Pavel Machek > Cc: Kalle Valo > Signed-off-by: Cong Wang Looks very reasonable. Acked-by: Pavel Machek I tried testing it, and resulting kernel works, but even going back to broken kernel I can't reproduce the problem on demand... Best regards, Pavel > +++ b/drivers/net/wireless/ti/wl1251/main.c > @@ -1571,6 +1571,7 @@ struct ieee80211_hw *wl1251_alloc_hw(void) > > wl->state = WL1251_STATE_OFF; > mutex_init(&wl->mutex); > + spin_lock_init(&wl->wl_lock); > > wl->tx_mgmt_frm_rate = DEFAULT_HW_GEN_TX_RATE; > wl->tx_mgmt_frm_mod = DEFAULT_HW_GEN_MODULATION_TYPE; -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
On Fri 2017-01-27 17:23:07, Kalle Valo wrote: > Pali Rohár writes: > > > On Friday 27 January 2017 14:26:22 Kalle Valo wrote: > >> Pali Rohár writes: > >> > >> > 2) It was already tested that example NVS data can be used for N900 e.g. > >> > for SSH connection. If real correct data are not available it is better > >> > to use at least those example (and probably log warning message) so user > >> > can connect via SSH and start investigating where is problem. > >> > >> I disagree. Allowing default calibration data to be used can be > >> unnoticed by user and left her wondering why wifi works so badly. > > > > So there are only two options: > > > > 1) Disallow it and so these users will have non-working wifi. > > > > 2) Allow those data to be used as fallback mechanism. > > > > And personally I'm against 1) because it will break wifi support for > > *all* Nokia N900 devices right now. > > All two of them? :) Umm. You clearly want a flock of angry penguins at your doorsteps :-). > But not working is exactly my point, if correct calibration data is not > available wifi should not work. And it's not only about functionality > problems, there's also the regulatory aspect. If you break existing configuration that's called "regression". > >> > 3) If we do rename *now* we will totally break wifi support on Nokia > >> > N900. > >> > >> Then the distro should fix that when updating the linux-firmware > >> packages. Can you provide details about the setup, what distro etc? > > > > Debian stable, Ubuntu LTSs 14.04, 16.04. > > You can run these out of box on N900? Debian stable does. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
Hi! > > You are probably saying that on your platform you can not remove > > anything from /lib/firmware, right? I don't see how you come from "it is > > part of firmware package" to "removing is not possible". Trying to > > understand this and it makes no sense. > > It is already in linux distribution packages. If I remove that file from > file system it will be placed there again by package management or it it > will throw error message about system integrity (missing file, etc...). > > Also that file is already in linux-firmware git and so is propagated to > /lib/firmware by anybody who is using linux-firmware. > > > >> Like we discussed earlier, the default nvs file should not be used by > > >> normal users. > > > > > > But already is and we need to deal with this fact. > > > > Why? > > Because everybody has already installed it. > > > Are there other platforms that use the default nvs file and have a > > working wifi. > > I do not know. > > > So your "removing is not possible" would be about > > regression for those? > > Yes, that is possible. > > Also you can use wifi on Nokia N900 with this default file. Yes it is > not recommended and probably has performance problems... but more people > use it for SSH and it is working. Pavel could confirm this. Yes, wifi somehow works on N900. .. depending on userspace and kernel versions. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: wl1251 & mac address & calibration data
Hi! > >> But overwriting that one file is not possible as it next update of > >> linux-firmware package will overwrite it back. It break any normal usage > >> of package management. > >> > >> Also it is ridiculously broken by design if some "boot" files needs to > >> be overwritten to initialize hardware properly. To not break booting you > >> need to overwrite that file before first boot. But without booting > >> device you cannot read calibration data. So some hack with autoreboot > >> after boot is needed. > > Providing the calibration data via Device Tree is the proper way to > solve this. Yes yes, I know N900 doesn't support it but that's a > deficiency in N900, not Linux. Linux has to work with whatever hardware provides. You may not like N900 design, but we have to support it, anyway. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
On Sun 2016-12-25 21:15:40, Arend Van Spriel wrote: > On 24-12-2016 17:52, Pali Rohár wrote: > > NVS calibration data for wl1251 are model specific. Every one device with > > wl1251 chip has different and calibrated in factory. > > > > Not all wl1251 chips have own EEPROM where are calibration data stored. And > > in that case there is no "standard" place. Every device has stored them on > > different place (some in rootfs file, some in dedicated nand partition, > > some in another proprietary structure). > > > > Kernel wl1251 driver cannot support every one different storage decided by > > device manufacture so it will use request_firmware_prefer_user() call for > > loading NVS calibration data and userspace helper will be responsible to > > prepare correct data. > > Responding to this patch as it provides a lot of context to discuss. As > you might have gathered from earlier discussions I am not a fan of using > user-space helper. I can agree that the kernel driver, wl1251 in this > case, should be agnostic to platform specific details regarding storage > solutions and the firmware api should hide that. However, it seems your > only solution is adding user-space to the mix and changing the api > towards that. Can we solve it without user-space help? Answer is no, due to licensing. But that's wrong question to ask. Right question is "should we solve it without user-space help"? Answer is no, too. Way too complex. Yes, it would be nice if hardware was designed in such a way that getting calibration data from kernel is easy, and if you design hardware, please design it like that. But N900 is not designed like that and getting the calibration through userspace looks like only reasonable solution. Now... how exactly to do that is other question. (But this is looks very reasonable. Maybe I'd add request_firmware_with_flags(, ...int flags), but.. that's a tiny detail.). But userspace needs to be involved. Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
Hi! > > > NVS calibration data for wl1251 are model specific. Every one > > > device with wl1251 chip has different and calibrated in factory. > > > > > > Not all wl1251 chips have own EEPROM where are calibration data > > > stored. And in that case there is no "standard" place. Every > > > device has stored them on different place (some in rootfs file, > > > some in dedicated nand partition, some in another proprietary > > > structure). > > > > > > Kernel wl1251 driver cannot support every one different storage > > > decided by device manufacture so it will use > > > request_firmware_prefer_user() call for loading NVS calibration > > > data and userspace helper will be responsible to prepare correct > > > data. > > > > Responding to this patch as it provides a lot of context to discuss. > > As you might have gathered from earlier discussions I am not a fan > > of using user-space helper. I can agree that the kernel driver, > > wl1251 in this case, should be agnostic to platform specific details > > regarding storage solutions and the firmware api should hide that. > > However, it seems your only solution is adding user-space to the mix > > and changing the api towards that. Can we solve it without > > user-space help? > > Without userspace helper it means that userspace helper code must be > integrated into kernel. > > So what is userspace helper doing? > > 1) Read MAC address from CAL > 2) Read NVS data from CAL > 3) Modify MAC address in memory NVS data (new for this patch series) > 4) Modify in memory NVS data if we in FCC country > > Checking for country is done via dbus call to either Maemo cellular > daemon or alternatively via REGDOMAIN in /etc/default/crda. I have plan > to use ofono (instead Maemo cellular daemon) too... > > Currently we are using closed Nokia proprietary CAL library. > > Steps 1) and 2) needs closed library, step 4) needs dbus call. I guess pointer to the source code implementing this would be welcome. > > But on other devices that use wl1251, but for instance have no > > userspace helper the request to userspace will fail (after 60 sec?) > > and try VFS after that. Maybe not so nice. > > Currently support for those devices is broken (like for N900) as without > proper NVS data they do not work correctly... Is it expected to work at all, perhaps with degraded performance / range? Because it seems to work for me. Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH 6/6] wl1251: Set generated MAC address back to NVS data
Hi!
> In case there is no valid MAC address kernel generates random one. This
> patch propagate this generated MAC address back to NVS data which will be
> uploaded to wl1251 chip. So HW would have same MAC address as linux kernel
> uses.
> return 0;
> }
>
> +static int wl1251_write_nvs_mac(struct wl1251 *wl)
> +{
The name is quite confusing, this sounds like writing into
non-volatile storage.
> + int i;
> +
> + if (wl->nvs_len < 0x24)
> + return -ENODATA;
> +
> + /* length is 2 and data address is 0x546c (mask is 0xfffe) */
You don't actually check for the mask.
> + if (wl->nvs[0x19] != 2 || wl->nvs[0x1a] != 0x6d || wl->nvs[0x1b] !=
> 0x54)
> + return -EINVAL;
You have two copies of these. Does it make sense to move it to helper
function?
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH 5/6] wl1251: Parse and use MAC address from supplied NVS data
On Sat 2016-12-24 17:53:00, Pali Rohár wrote:
> This patch implements parsing MAC address from NVS data which are sent to
> wl1251 chip. Calibration NVS data could contain valid MAC address and it
> will be used instead randomly generated.
will be used instead of randomly generated one.
> This patch also move code for requesting NVS data from userspace to driver
"moves"
> initialization code to make sure that NVS data will be there at time when
> permanent MAC address is needed.
"at a time"
> Calibration NVS data for wl1251 are model specific. Every one device with
"device specific"? "Every device".
> wl1251 chip should have been calibrated in factory and needs to provide own
> calibration data.
>
> Default example wl1251-nvs.bin data found in linux-firmware repository and
"are found"
> contains MAC address 00:00:20:07:03:09. So this MAC address is marked as
"contain"
> invalid as it is not real device specific address, just example one.
>
> Format of calibration NVS data can be found at:
> http://notaz.gp2x.de/misc/pnd/wl1251/nvs_map.txt
>
> Signed-off-by: Pali Rohár
> ---
> drivers/net/wireless/ti/wl1251/main.c | 39
> ++---
> 1 file changed, 31 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/wireless/ti/wl1251/main.c
> b/drivers/net/wireless/ti/wl1251/main.c
> index c3fa0b6..1454ba2 100644
> --- a/drivers/net/wireless/ti/wl1251/main.c
> +++ b/drivers/net/wireless/ti/wl1251/main.c
> @@ -205,13 +205,6 @@ static int wl1251_chip_wakeup(struct wl1251 *wl)
> goto out;
> }
>
> - if (wl->nvs == NULL && !wl->use_eeprom) {
> - /* No NVS from netlink, try to get it from the filesystem */
> - ret = wl1251_fetch_nvs(wl);
> - if (ret < 0)
> - goto out;
> - }
> -
> out:
> return ret;
> }
> @@ -1538,6 +1531,30 @@ static int wl1251_read_eeprom_mac(struct wl1251 *wl)
> return 0;
> }
>
> +static int wl1251_read_nvs_mac(struct wl1251 *wl)
> +{
> + u8 mac[ETH_ALEN];
> + int i;
> +
> + if (wl->nvs_len < 0x24)
> + return -ENODATA;
> +
> + /* length is 2 and data address is 0x546c (mask is 0xfffe) */
> + if (wl->nvs[0x19] != 2 || wl->nvs[0x1a] != 0x6d || wl->nvs[0x1b] !=
> 0x54)
> + return -EINVAL;
> +
> + /* MAC is stored in reverse order */
> + for (i = 0; i < ETH_ALEN; i++)
> + mac[i] = wl->nvs[0x1c + ETH_ALEN - i - 1];
> +
> + /* 00:00:20:07:03:09 is in default example wl1251-nvs.bin, so invalid */
remove "default".
> + if (ether_addr_equal_unaligned(mac, "\x00\x00\x20\x07\x03\x09"))
> + return -EINVAL;
> +
> + memcpy(wl->mac_addr, mac, ETH_ALEN);
> + return 0;
> +}
> +
> static int wl1251_register_hw(struct wl1251 *wl)
> {
> int ret;
> @@ -1581,10 +1598,16 @@ int wl1251_init_ieee80211(struct wl1251 *wl)
>
> wl->hw->queues = 4;
>
> + if (wl->nvs == NULL && !wl->use_eeprom) {
> + ret = wl1251_fetch_nvs(wl);
> + if (ret < 0)
> + goto out;
> + }
Is goto out here good idea? IMNSHO it is copy&paste bug, it should
just proceed with generating random address.
> if (wl->use_eeprom)
> ret = wl1251_read_eeprom_mac(wl);
> else
> - ret = -EINVAL;
> + ret = wl1251_read_nvs_mac(wl);
>
> if (ret == 0 && !is_valid_ether_addr(wl->mac_addr))
> ret = -EINVAL;
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH 4/6] wl1251: Generate random MAC address only if driver does not have valid
On Sat 2016-12-24 17:52:59, Pali Rohár wrote: > Before this patch driver generated random MAC address every time when was > doing initialization. And after that random MAC address could be > overwritten with fixed one if provided. Before this patch, driver generated random MAC address every time it was initialized. After that random MAC address could be overwritten with fixed one, if provided. > This patch changes order. First it tries to read fixed MAC address and if > it fails then driver generates random MAC address. I don't quite get where the advantage is supposed to be. Is it that "use_eeprom" is set, but reading fails? The only case where this helps is if wl1251_read_eeprom_mac() succeeds but reads invalid address. > Signed-off-by: Pali Rohár Acked-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH 3/6] wl1251: Update wl->nvs_len after wl->nvs is valid
On Sat 2016-12-24 17:52:58, Pali Rohár wrote:
> In case kmemdup fails thne wl->nvs_len will contains invalid non-zero size.
> This patch fixes it.
If kmemdup fails, then wl->nvs_len will contain invalid non-zero size.
?
This probably should go as first in series, as it is bugfix?
Pavel
Acked-by: Pavel Machek
> Signed-off-by: Pali Rohár
> ---
> drivers/net/wireless/ti/wl1251/main.c |5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ti/wl1251/main.c
> b/drivers/net/wireless/ti/wl1251/main.c
> index 24f8866..8971b64 100644
> --- a/drivers/net/wireless/ti/wl1251/main.c
> +++ b/drivers/net/wireless/ti/wl1251/main.c
> @@ -124,8 +124,7 @@ static int wl1251_fetch_nvs(struct wl1251 *wl)
> goto out;
> }
>
> - wl->nvs_len = fw->size;
> - wl->nvs = kmemdup(fw->data, wl->nvs_len, GFP_KERNEL);
> + wl->nvs = kmemdup(fw->data, fw->size, GFP_KERNEL);
>
> if (!wl->nvs) {
> wl1251_error("could not allocate memory for the nvs file");
> @@ -133,6 +132,8 @@ static int wl1251_fetch_nvs(struct wl1251 *wl)
> goto out;
> }
>
> + wl->nvs_len = fw->size;
> +
> ret = 0;
>
> out:
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: wl1251 & mac address & calibration data
On Thu 2016-11-24 20:46:01, Aaro Koskinen wrote: > Hi, > > On Thu, Nov 24, 2016 at 04:20:45PM +0100, Pali Rohár wrote: > > Proprietary, signed and closed bootloader NOLO does not support DT. So > > for booting you need to append DTS file to kernel image. > > > > U-Boot is optional and can be used as intermediate bootloader between > > NOLO and kernel. But still it has problems with reading from nand, so > > cannot read NVS data nor MAC address. > > You could use kexec to pass the fixed DT. Yeah. You could also strap desktop PC to a USB GPRS card, and call it phone. You could also make a pig fly. But because you could does not mean you should. No, sorry, kexec is not acceptable. Too hard to set up, slows boot too much. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: wl1251 & mac address & calibration data
Hi! > > "ifconfig hw ether XX" normally sets the address. I guess that's > > ioctl? > > This sets temporary address and it is ioctl. IIRC same as what ethtool > uses. (ifconfig is already deprecated). > > > And I guess we should use similar mechanism for permanent > > address. > > I'm not sure here... Above ioctl ↑↑↑ is for changing temporary mac > address. But here we do not want to change permanent mac address. We > want to tell kernel driver current permanent mac address which is > stored Well... I'd still use similar mechanism :-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: wl1251 & mac address & calibration data
Hi! > > > As wl1251.ko does not accept mac_address as module parameter, such > > > modprobe hook does not help -- as there is absolutely no way from > > > userspace to set or change (permanent) mac address. > > > > Quoting modprobe.d manual: > > > install modulename command... > > > > > > This command instructs modprobe to run your > > > command instead of inserting the module in the > > > kernel as normal. The command can be any shell > > > command: this allows you to do any kind of > > > complex processing you might wish. [...] > > I know. But this do not allow me to send mac address to kernel -- as > kernel does not support such command yet (reason for my first > question). Plus, this does not really work for cases where wl1251 is not a module. > > You can hook up a script that cooks up wl1251-nvs.bin (caldata, > > macaddr) and then insmod the actual wl1251.ko module. Or you can just > > cook up the nvs on first device boot and store it in /lib/firmware > > (possibly overwriting the "generic" wl1251 from linux-firmware). > > This is what I would like to prevent -- overwriting (possible readonly) > system files with some device specific. It is really bad idea! Agreed. "ifconfig hw ether XX" normally sets the address. I guess that's ioctl? And I guess we should use similar mechanism for permanent address. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: N900, wl1251: wifi is now slow, even with powersave off
On Sun 2016-06-19 00:55:54, Pavel Machek wrote: > Hi! > > > Ping to N900: > > > > 64 bytes from maemo (10.0.0.8): icmp_seq=187 ttl=64 time=124 ms > > rtt min/avg/max/mdev = 4.382/101.866/453.145/42.395 ms > > root@duo:/data/pavel# > > > > Now on n900: > > > > pavel@n900:/my/tui/ofone$ sudo iw dev wlan0 set power_save off > > pavel@n900:/my/tui/ofone$ > > > > That should bring ping back to < 2 msec range, but nothing changes: > > > > root@duo:/data/pavel# ping maemo > > PING maemo (10.0.0.8) 56(84) bytes of data. > > 64 bytes from maemo (10.0.0.8): icmp_seq=1 ttl=64 time=78.5 ms > > rtt min/avg/max/mdev = 18.298/68.025/118.223/30.756 ms > > root@duo:/data/pavel# > > > > Any ideas what is going on there? > > v4.4: works ok, rtt min/avg/max/mdev = 2.111/2.243/2.524/0.150 ms > v4.5-rc0: can't get wifi to work. v4.5: slow as described. > v4.6: slow as described. > v4.7-rc3: slow as described. Hmm. If wifi is truly broken in -rc0, I'm looking for some fun bisect :-(. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: N900, wl1251: wifi is now slow, even with powersave off
Hi! > Ping to N900: > > 64 bytes from maemo (10.0.0.8): icmp_seq=187 ttl=64 time=124 ms > rtt min/avg/max/mdev = 4.382/101.866/453.145/42.395 ms > root@duo:/data/pavel# > > Now on n900: > > pavel@n900:/my/tui/ofone$ sudo iw dev wlan0 set power_save off > pavel@n900:/my/tui/ofone$ > > That should bring ping back to < 2 msec range, but nothing changes: > > root@duo:/data/pavel# ping maemo > PING maemo (10.0.0.8) 56(84) bytes of data. > 64 bytes from maemo (10.0.0.8): icmp_seq=1 ttl=64 time=78.5 ms > rtt min/avg/max/mdev = 18.298/68.025/118.223/30.756 ms > root@duo:/data/pavel# > > Any ideas what is going on there? v4.4: works ok, rtt min/avg/max/mdev = 2.111/2.243/2.524/0.150 ms v4.5-rc0: can't get wifi to work. v4.6: slow as described. v4.7-rc3: slow as described. Even confirming you see same problem would help :-). Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
N900, wl1251: wifi is now slow, even with powersave off
Hi! Ping to N900: 64 bytes from maemo (10.0.0.8): icmp_seq=187 ttl=64 time=124 ms 64 bytes from maemo (10.0.0.8): icmp_seq=188 ttl=64 time=131 ms 64 bytes from maemo (10.0.0.8): icmp_seq=189 ttl=64 time=66.7 ms ^C --- maemo ping statistics --- 189 packets transmitted, 189 received, 0% packet loss, time 188742ms rtt min/avg/max/mdev = 4.382/101.866/453.145/42.395 ms root@duo:/data/pavel# Now on n900: pavel@n900:/my/tui/ofone$ sudo iw dev wlan0 set power_save off pavel@n900:/my/tui/ofone$ That should bring ping back to < 2 msec range, but nothing changes: root@duo:/data/pavel# ping maemo PING maemo (10.0.0.8) 56(84) bytes of data. 64 bytes from maemo (10.0.0.8): icmp_seq=1 ttl=64 time=78.5 ms 64 bytes from maemo (10.0.0.8): icmp_seq=2 ttl=64 time=101 ms 64 bytes from maemo (10.0.0.8): icmp_seq=3 ttl=64 time=18.2 ms 64 bytes from maemo (10.0.0.8): icmp_seq=4 ttl=64 time=37.5 ms 64 bytes from maemo (10.0.0.8): icmp_seq=5 ttl=64 time=58.2 ms 64 bytes from maemo (10.0.0.8): icmp_seq=6 ttl=64 time=77.6 ms 64 bytes from maemo (10.0.0.8): icmp_seq=7 ttl=64 time=98.3 ms 64 bytes from maemo (10.0.0.8): icmp_seq=8 ttl=64 time=118 ms 64 bytes from maemo (10.0.0.8): icmp_seq=9 ttl=64 time=35.8 ms 64 bytes from maemo (10.0.0.8): icmp_seq=10 ttl=64 time=55.7 ms ^C --- maemo ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9034ms rtt min/avg/max/mdev = 18.298/68.025/118.223/30.756 ms root@duo:/data/pavel# Any ideas what is going on there? Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 1/3] rfkill: Create "rfkill-airplane-mode" LED trigger
On Mon 2016-06-13 17:10:02, João Paulo Rechi Vita wrote: > On 13 June 2016 at 17:01, Pavel Machek wrote: > > On Mon 2016-06-13 15:59:35, João Paulo Rechi Vita wrote: > >> On 13 June 2016 at 15:00, Pavel Machek wrote: > >> > Hi! > >> > > >> >> > João, that means you should send a patch to add the ::rfkill suffix. > >> >> > > >> >> > >> >> IMO "airplane" (or maybe "airplane-mode") is a better suffix, as it > >> >> reflects the label on the machine's chassis. I'll name it > >> >> "asus-wireless::airplane" and send this through platform-drivers-x86, > >> >> as this is now contained in the platform-drivers-x86 subsystem. Thanks > >> >> Johannes for your patience and help designing and reviewing the rfkill > >> >> changes, even if not all of them made it through in the end. And > >> >> thanks everyone else involved for the feedback. > >> > > >> > Actually, I'd do '::rfkill', for consistency with other places in > >> > /sys. > >> > > >> > /sys/devices/platform/thinkpad_acpi/rfkill/rfkill1/name > >> > /sys/class/rfkill > >> > /sys/module/rfkill > >> > > >> > >> If we use "rfkill" as a suffix, how do you expect userspace to be able > >> to differentiate between a LED that indicates airplane-mode (LED ON > >> when all radios are OFF) and a LED that indicates the state of a > >> specific radio like WiFi or Bluetooth (LED ON when that specific radio > >> is ON)? If we're going this route we should provide meaningful > >> information here. > > > > '::airplane' has same problem, no? > > > > No, because in this case we would not use "airplane" as a suffix for a > LED associated with an individual radio. > > > If you want to distinguish that, maybe you can do '::rfkill' for > > everything vs '::rfkill-wifi' for wifi-only and '::rfkill-bt' for > > bluetooth... > > > > The problem here is that the "rfkill" name is already associated with > individual rfkill switches under /sys/class/rfkill, > /sys/devices/platform/*/rfkill etc, so I think we're better off > distinguishing "airplane" vs "wifi" vs "bluetooth" etc, to avoid > confusion. (Actually, "::wifi" is super confusing, I'd expect that to be a led that blinks when wifi is active.) Well... "airplane" is quite confusing. I'd we use "rfkill" for disabling radios, and I believe we should stick with that. But small problem might be polarity. You may need both "::rfkill" and "::not-rfkill". Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 1/3] rfkill: Create "rfkill-airplane-mode" LED trigger
On Mon 2016-06-13 15:59:35, João Paulo Rechi Vita wrote: > On 13 June 2016 at 15:00, Pavel Machek wrote: > > Hi! > > > >> > João, that means you should send a patch to add the ::rfkill suffix. > >> > > >> > >> IMO "airplane" (or maybe "airplane-mode") is a better suffix, as it > >> reflects the label on the machine's chassis. I'll name it > >> "asus-wireless::airplane" and send this through platform-drivers-x86, > >> as this is now contained in the platform-drivers-x86 subsystem. Thanks > >> Johannes for your patience and help designing and reviewing the rfkill > >> changes, even if not all of them made it through in the end. And > >> thanks everyone else involved for the feedback. > > > > Actually, I'd do '::rfkill', for consistency with other places in > > /sys. > > > > /sys/devices/platform/thinkpad_acpi/rfkill/rfkill1/name > > /sys/class/rfkill > > /sys/module/rfkill > > > > If we use "rfkill" as a suffix, how do you expect userspace to be able > to differentiate between a LED that indicates airplane-mode (LED ON > when all radios are OFF) and a LED that indicates the state of a > specific radio like WiFi or Bluetooth (LED ON when that specific radio > is ON)? If we're going this route we should provide meaningful > information here. '::airplane' has same problem, no? If you want to distinguish that, maybe you can do '::rfkill' for everything vs '::rfkill-wifi' for wifi-only and '::rfkill-bt' for bluetooth... Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 1/3] rfkill: Create "rfkill-airplane-mode" LED trigger
Hi! > > João, that means you should send a patch to add the ::rfkill suffix. > > > > IMO "airplane" (or maybe "airplane-mode") is a better suffix, as it > reflects the label on the machine's chassis. I'll name it > "asus-wireless::airplane" and send this through platform-drivers-x86, > as this is now contained in the platform-drivers-x86 subsystem. Thanks > Johannes for your patience and help designing and reviewing the rfkill > changes, even if not all of them made it through in the end. And > thanks everyone else involved for the feedback. Actually, I'd do '::rfkill', for consistency with other places in /sys. /sys/devices/platform/thinkpad_acpi/rfkill/rfkill1/name /sys/class/rfkill /sys/module/rfkill Thanks for patience, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 1/3] rfkill: Create "rfkill-airplane-mode" LED trigger
On Thu 2016-05-12 11:32:52, Johannes Berg wrote: > On Wed, 2016-05-04 at 09:29 +0200, Pavel Machek wrote: > > > > If userspace wants to control the manually, it can do just that -- > > control it manually. There should not be a need to "override the > > default policy". > > I'm still not buying this. > > In the original situation, without these patches, userspace has to have > a list of all LEDs that are supposed to indicate airplane mode. Well, that's situation for many LEDs. > With this patch only (without patch 2/3), userspace can look up the > default trigger, but then has to change it, causing the necessary > information to be lost immediately when you actually use it - that also > seems like a bad idea. We should not store "what kind of led this is" in a trigger. LED subsystem seems to use suffix of LED name to do that. So if we standartize, lets say "::rfkill" suffix for this, it should work and follow existing practice. > Now, if the LED subsystem had a really good way of specifying LED > intent, and it was widely used, and rfkill didn't already concern > itself with the rfkill status of all devices ... yeah maybe this > wouldn't be needed. As it stands, I still think this is the best way > forward. There is one -- suffix in the LED name. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 1/3] rfkill: Create "rfkill-airplane-mode" LED trigger
Hi! > This creates a new LED trigger to be used by platform drivers as a > default trigger for airplane-mode indicator LEDs. > > By default this trigger will fire when RFKILL_OP_CHANGE_ALL is called > for all types (RFKILL_TYPE_ALL), setting the LED brightness to LED_FULL > when the changing the state to blocked, and to LED_OFF when the changing > the state to unblocked. In the future there will be a mechanism for > userspace to override the default policy, so it can implement its > own. If userspace wants to control the manually, it can do just that -- control it manually. There should not be a need to "override the default policy". Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4.6-rc5 on arm (nokia n900): spinlock bad magic on CPU#0,
On Mon 2016-04-25 16:59:33, Pavel Machek wrote: > Hi! > > > First time such thing happened, normally N900 is very stable. > > Second time, within a day. It seems rather repeatable. I tested 4.4 > rather heavily, and seen any backtraces... > > Oh, and some saboteur seemed to turn on ipv6 on my wifi. Probably > unrelated Happened again today. Definitely a regression from 4.4... Pavel [ 266.151550] BUG: spinlock bad magic on CPU#0, kworker/u2:0/6 [ 266.151611] lock: 0xcd644f40, .magic: , .owner: /-1, .owner_cpu: 0 [ 266.151641] CPU: 0 PID: 6 Comm: kworker/u2:0 Tainted: GW 4.6.0-rc5-176860-gd6fbb13-dirty #251 [ 266.151672] Hardware name: Nokia RX-51 board [ 266.151702] Workqueue: phy1 wl1251_irq_work [ 266.151794] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 266.151824] [] (show_stack) from [] (dump_stack+0x8c/0xac) [ 266.151855] [] (dump_stack) from [] (do_raw_spin_lock+0x198/0x1b8) [ 266.151916] [] (do_raw_spin_lock) from [] (_raw_spin_lock_irqsave+0x10/0x18) [ 266.151947] [] (_raw_spin_lock_irqsave) from [] (wl1251_op_tx+0x38/0x5c) [ 266.151977] [] (wl1251_op_tx) from [] (ieee80211_tx_frags+0xd0/0x3d4) [ 266.152008] [] (ieee80211_tx_frags) from [] (__ieee80211_tx+0x6c/0x134) [ 266.152069] [] (__ieee80211_tx) from [] (ieee80211_tx+0xb4/0xdc) [ 266.152099] [] (ieee80211_tx) from [] (__ieee80211_subif_start_xmit+0x540/0x6d0) [ 266.152130] [] (__ieee80211_subif_start_xmit) from [] (ieee80211_subif_start_xmit+0xc/0x14) [ 266.152160] [] (ieee80211_subif_start_xmit) from [] (dev_hard_start_xmit+0x228/0x440) [ 266.152191] [] (dev_hard_start_xmit) from [] (sch_direct_xmit+0xf4/0x220) [ 266.152221] [] (sch_direct_xmit) from [] (__dev_queue_xmit+0x25c/0x62c) [ 266.152252] [] (__dev_queue_xmit) from [] (ip_finish_output2+0x1a0/0x3d0) [ 266.152282] [] (ip_finish_output2) from [] (ip_output+0x130/0x144) [ 266.152313] [] (ip_output) from [] (ip_local_out+0x38/0x3c) [ 266.152343] [] (ip_local_out) from [] (tcp_transmit_skb+0x510/0x984) [ 266.152404] [] (tcp_transmit_skb) from [] (tcp_rcv_established+0x360/0x728) [ 266.152435] [] (tcp_rcv_established) from [] (tcp_v4_do_rcv+0x14c/0x1b0) [ 266.152465] [] (tcp_v4_do_rcv) from [] (tcp_v4_rcv+0xc3c/0xc58) [ 266.152496] [] (tcp_v4_rcv) from [] (ip_local_deliver_finish+0x5c/0x29c) [ 266.152526] [] (ip_local_deliver_finish) from [] (ip_local_deliver+0xd0/0xd8) [ 266.152557] [] (ip_local_deliver) from [] (ip_rcv_finish+0x1f0/0x458) [ 266.152587] [] (ip_rcv_finish) from [] (ip_rcv+0x39c/0x56c) [ 266.152618] [] (ip_rcv) from [] (__netif_receive_skb_core+0x2e8/0x958) [ 266.152648] [] (__netif_receive_skb_core) from [] (netif_receive_skb_internal+0x30/0xa0) [ 266.152679] [] (netif_receive_skb_internal) from [] (ieee80211_deliver_skb+0x184/0x1bc) [ 266.152709] [] (ieee80211_deliver_skb) from [] (ieee80211_rx_handlers+0xe9c/0x201c) [ 266.152740] [] (ieee80211_rx_handlers) from [] (ieee80211_prepare_and_rx_handle+0x1b8/0x9b4) [ 266.152770] [] (ieee80211_prepare_and_rx_handle) from [] (ieee80211_rx_napi+0x680/0x7f0) [ 266.152832] [] (ieee80211_rx_napi) from [] (wl1251_rx+0x324/0x49c) [ 266.152862] [] (wl1251_rx) from [] (wl1251_irq_work+0x144/0x1b0) [ 266.152893] [] (wl1251_irq_work) from [] (process_one_work+0x130/0x428) [ 266.152923] [] (process_one_work) from [] (worker_thread+0x15c/0x490) [ 266.152954] [] (worker_thread) from [] (kthread+0xd4/0xf0) [ 266.152984] [] (kthread) from [] (ret_from_fork+0x14/0x3c) -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4.6-rc5 on arm (nokia n900): spinlock bad magic on CPU#0,
Hi! > First time such thing happened, normally N900 is very stable. Second time, within a day. It seems rather repeatable. I tested 4.4 rather heavily, and seen any backtraces... Oh, and some saboteur seemed to turn on ipv6 on my wifi. Probably unrelated Best regards, Pavel [ 157.867431] DSS: dss_save_context [ 157.867462] DSS: context saved [ 322.248291] BUG: spinlock bad magic on CPU#0, kworker/u2:3/2693 [ 322.248687] lock: 0xce670f40, .magic: , .owner: /-1, .owner_cpu: 0 [ 322.249114] CPU: 0 PID: 2693 Comm: kworker/u2:3 Not tainted 4.6.0-rc5-176733-g8b658a3-dirty #244 [ 322.249603] Hardware name: Nokia RX-51 board [ 322.249877] Workqueue: phy1 wl1251_irq_work [ 322.250183] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 322.250640] [] (show_stack) from [] (dump_stack+0x8c/0xac) [ 322.251068] [] (dump_stack) from [] (do_raw_spin_lock+0x198/0x1b8) [ 322.251495] [] (do_raw_spin_lock) from [] (_raw_spin_lock_irqsave+0x10/0x18) [ 322.251922] [] (_raw_spin_lock_irqsave) from [] (wl1251_op_tx+0x38/0x5c) [ 322.252380] [] (wl1251_op_tx) from [] (ieee80211_tx_frags+0xd0/0x3d4) [ 322.252807] [] (ieee80211_tx_frags) from [] (__ieee80211_tx+0x6c/0x134) [ 322.253234] [] (__ieee80211_tx) from [] (ieee80211_tx+0xb4/0xdc) [ 322.253631] [] (ieee80211_tx) from [] (__ieee80211_subif_start_xmit+0x540/0x6d0) [ 322.254089] [] (__ieee80211_subif_start_xmit) from [] (ieee80211_subif_start_xmit+0xc/0x14) [ 322.254608] [] (ieee80211_subif_start_xmit) from [] (dev_hard_start_xmit+0x228/0x440) [ 322.255096] [] (dev_hard_start_xmit) from [] (sch_direct_xmit+0xf4/0x220) [ 322.255523] [] (sch_direct_xmit) from [] (__dev_queue_xmit+0x25c/0x62c) [ 322.255981] [] (__dev_queue_xmit) from [] (ip_finish_output2+0x1a0/0x3d0) [ 322.256408] [] (ip_finish_output2) from [] (ip_output+0x130/0x144) [ 322.256805] [] (ip_output) from [] (ip_local_out+0x38/0x3c) [ 322.257202] [] (ip_local_out) from [] (tcp_transmit_skb+0x510/0x984) [ 322.257598] [] (tcp_transmit_skb) from [] (tcp_rcv_established+0x360/0x728) [ 322.258056] [] (tcp_rcv_established) from [] (tcp_v4_do_rcv+0x14c/0x1b0) [ 322.258483] [] (tcp_v4_do_rcv) from [] (tcp_v4_rcv+0xc3c/0xc58) [ 322.258880] [] (tcp_v4_rcv) from [] (ip_local_deliver_finish+0x5c/0x29c) [ 322.268096] [] (ip_local_deliver_finish) from [] (ip_local_deliver+0xd0/0xd8) [ 322.277374] [] (ip_local_deliver) from [] (ip_rcv_finish+0x1f0/0x458) [ 322.286590] [] (ip_rcv_finish) from [] (ip_rcv+0x39c/0x56c) [ 322.295715] [] (ip_rcv) from [] (__netif_receive_skb_core+0x2e8/0x958) [ 322.304809] [] (__netif_receive_skb_core) from [] (netif_receive_skb_internal+0x30/0xa0) [ 322.323059] [] (netif_receive_skb_internal) from [] (ieee80211_deliver_skb+0x184/0x1bc) [ 322.341827] [] (ieee80211_deliver_skb) from [] (ieee80211_rx_handlers+0xe9c/0x201c) [ 322.360961] [] (ieee80211_rx_handlers) from [] (ieee80211_prepare_and_rx_handle+0x1b8/0x9b4) [ 322.380493] [] (ieee80211_prepare_and_rx_handle) from [] (ieee80211_rx_napi+0x680/0x7f0) [ 322.400390] [] (ieee80211_rx_napi) from [] (wl1251_rx+0x324/0x49c) [ 322.410522] [] (wl1251_rx) from [] (wl1251_irq_work+0x154/0x1b0) [ 322.420532] [] (wl1251_irq_work) from [] (process_one_work+0x130/0x428) [ 322.430450] [] (process_one_work) from [] (worker_thread+0x15c/0x490) [ 322.440277] [] (worker_thread) from [] (kthread+0xd4/0xf0) [ 322.449951] [] (kthread) from [] (ret_from_fork+0x14/0x3c) pavel@n900:/my$ -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
4.6-rc5 on arm (nokia n900): spinlock bad magic on CPU#0,
Hi! First time such thing happened, normally N900 is very stable. Any ideas? Pavel [ 6274.123779] DSS: context saved [ 6410.643981] BUG: spinlock bad magic on CPU#0, kworker/u2:1/18947 [ 6410.644409] lock: 0xce648f40, .magic: , .owner: /-1, .owner_cpu: 0 [ 6410.644836] CPU: 0 PID: 18947 Comm: kworker/u2:1 Not tainted 4.6.0-rc5-176732-g177b741-dirty #243 [ 6410.647949] Hardware name: Nokia RX-51 board [ 6410.650909] Workqueue: phy1 wl1251_irq_work [ 6410.653869] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 6410.657135] [] (show_stack) from [] (dump_stack+0x8c/0xac) [ 6410.660583] [] (dump_stack) from [] (do_raw_spin_lock+0x198/0x1b8) [ 6410.664245] [] (do_raw_spin_lock) from [] (_raw_spin_lock_irqsave+0x10/0x18) [ 6410.668243] [] (_raw_spin_lock_irqsave) from [] (wl1251_op_tx+0x38/0x5c) [ 6410.672485] [] (wl1251_op_tx) from [] (ieee80211_tx_frags+0xd0/0x3d4) [ 6410.677001] [] (ieee80211_tx_frags) from [] (__ieee80211_tx+0x6c/0x134) [ 6410.681793] [] (__ieee80211_tx) from [] (ieee80211_tx+0xb4/0xdc) [ 6410.686828] [] (ieee80211_tx) from [] (__ieee80211_subif_start_xmit+0x540/0x6d0) [ 6410.697448] [] (__ieee80211_subif_start_xmit) from [] (ieee80211_subif_start_xmit+0xc/0x14) [ 6410.709625] [] (ieee80211_subif_start_xmit) from [] (dev_hard_start_xmit+0x228/0x440) [ 6410.723205] [] (dev_hard_start_xmit) from [] (sch_direct_xmit+0xf4/0x220) [ 6410.730712] [] (sch_direct_xmit) from [] (__dev_queue_xmit+0x25c/0x62c) [ 6410.738494] [] (__dev_queue_xmit) from [] (ip_finish_output2+0x1b8/0x3d0) [ 6410.746551] [] (ip_finish_output2) from [] (ip_output+0x130/0x144) [ 6410.754852] [] (ip_output) from [] (ip_local_out+0x38/0x3c) [ 6410.763366] [] (ip_local_out) from [] (tcp_transmit_skb+0x510/0x984) [ 6410.772003] [] (tcp_transmit_skb) from [] (tcp_rcv_established+0x360/0x728) [ 6410.780822] [] (tcp_rcv_established) from [] (tcp_v4_do_rcv+0x14c/0x1b0) [ 6410.789764] [] (tcp_v4_do_rcv) from [] (tcp_v4_rcv+0xc3c/0xc58) [ 6410.798919] [] (tcp_v4_rcv) from [] (ip_local_deliver_finish+0x5c/0x29c) [ 6410.808197] [] (ip_local_deliver_finish) from [] (ip_local_deliver+0xd0/0xd8) [ 6410.817565] [] (ip_local_deliver) from [] (ip_rcv_finish+0x1f0/0x458) [ 6410.826873] [] (ip_rcv_finish) from [] (ip_rcv+0x39c/0x56c) [ 6410.836059] [] (ip_rcv) from [] (__netif_receive_skb_core+0x2e8/0x958) [ 6410.845214] [] (__netif_receive_skb_core) from [] (netif_receive_skb_internal+0x30/0xa0) [ 6410.863647] [] (netif_receive_skb_internal) from [] (ieee80211_deliver_skb+0x184/0x1bc) [ 6410.882598] [] (ieee80211_deliver_skb) from [] (ieee80211_rx_handlers+0xe9c/0x201c) [ 6410.901916] [] (ieee80211_rx_handlers) from [] (ieee80211_prepare_and_rx_handle+0x1b8/0x9b4) [ 6410.921600] [] (ieee80211_prepare_and_rx_handle) from [] (ieee80211_rx_napi+0x680/0x7f0) [ 6410.941650] [] (ieee80211_rx_napi) from [] (wl1251_rx+0x324/0x49c) [ 6410.951843] [] (wl1251_rx) from [] (wl1251_irq_work+0x154/0x1b0) [ 6410.961944] [] (wl1251_irq_work) from [] (process_one_work+0x130/0x428) [ 6410.971923] [] (process_one_work) from [] (worker_thread+0x15c/0x490) [ 6410.981842] [] (worker_thread) from [] (kthread+0xd4/0xf0) [ 6410.991577] [] (kthread) from [] (ret_from_fork+0x14/0x3c) [ 6417.062316] DISPC: dispc_runtime_get [ 6417.062408] DSS: dss_restore_context [ 6417.062408] DSS: context restored -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AP firmware for TI wl1251 wifi chip (wl1251-fw-ap.bin)
Hi! > > > wl1251 does not support AP mode, so there is no firmware for it in > > > the tree. > > > > > > Regards, > > > Yaniv > > > > Hi Yaniv! I read on some TI whitepaper, that wl1251 hardware supports > > some Soft-AP mode. So I expect that either special FW is needed for it > > or somehow it is possible to use current released. Do you have any > > information about it? > > Hi Pali, > This must be some typo, the device does not support Soft-AP. > More than that, wl1251 family is not officially supported via the mainline > Linux. > For Soft-AP, and other new features based on Linux you should use WiLink8 > chip family. Too late for that, we already have the devices, and they were manufactured quite long time ago. Is it "hardware can't do AP", "firmware can't do AP" or "current drivers do not support AP"? Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: custom ioctl-based interface to control LED in networking (was Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode)
On Wed 2016-02-24 14:31:33, Johannes Berg wrote: > On Wed, 2016-02-24 at 13:14 +0100, Pavel Machek wrote: > > > > Why would it need to? It could look at default triggers for the led > > if it really wanted to. > > And then it needs to change them; if anything goes wrong error recovery > is practically impossible since the trigger information is lost > forever. Well, conventional way to solve this is to simply name the led "acer::airplane"... that way it is persistent. We already do that for display/keyboard backlights. > It's not my position to decide which combinations some system > integrator or userspace developer might find useful. > > Even when we add parameters to a trigger (I don't see a generic way to > do that, but please do enlighten me), you're now ignoring the issue of > the userspace controlled GSM modem... Take a look at the blinking triggers. > > > Really what you have here is a concept of "airplane mode", and that > > > concept is specific to the rfkill subsystem. This happens to affect > > > mostly an LED trigger, today, but as a concept it's something that > > > *should* be managed within the rfkill subsystem. > > > > How is that concept used outside the LEDs? What semantics does > > "airplane mode" have? You tried to explain "airplane mode" is not > > well defined up in this thread... > > I'd say it's well-defined for any given set of system software, so if > e.g. NetworkManager decides to define it one way, and connman another > way, there's a definition but the kernel need not interfere with it. So... the LED changes meaning during boot? That's surely not a nice solution. So... you rather store bit in a kernel with unclear semantics, explaining "oh I need to leave the flexibility to userland"? Sorry, that's just ugly. > > I'm not saying that. I'm saying that LED maintainers should be Cced, > > to keep the interfaces consistent. > > I pretty much have to read it that way, since the LED API is in no way > impacted by these changes. Here's a new trigger, with some magic inner > working. No impact on the LED API. New LED trigger and new ioctl for LED control... not matching how LEDs are normally controlled. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: custom ioctl-based interface to control LED in networking (was Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode)
On Wed 2016-02-24 12:01:37, Johannes Berg wrote: > On Wed, 2016-02-24 at 11:46 +0100, Pavel Machek wrote: > > > If you want different trigger, implement different trigger. If you > > want to indicate all but wifi, implement all but wifi, and then > > userspace can select it by writing trigger name. > > This is still mostly a strawman, since userspace cannot have a database > of LEDs that indicate airplane mode. Why would it need to? It could look at default triggers for the led if it really wanted to. > I'm sure you'd also not like to see 2**7 triggers implemented in rfkill > to cover all the possibilities. Are all the possibilities useful? I assumed about 2 are. If you need 2**7 of them, LED triggers can have parameters. > > If you want complete > > userspace control, fine, but we have standard interface and it is not > > ioctl. > > The "standard interface" is usable if you really just want to driver a > single LED and you know which one. > > I think you're looking at this the wrong way, focusing too much on the > LED aspect. > > Really what you have here is a concept of "airplane mode", and that > concept is specific to the rfkill subsystem. This happens to affect > mostly an LED trigger, today, but as a concept it's something that > *should* be managed within the rfkill subsystem. How is that concept used outside the LEDs? What semantics does "airplane mode" have? You tried to explain "airplane mode" is not well defined up in this thread... > > Besides, the series really should have been Cc-ed to LED > > people, too. > > That's simply unreasonable, you're essentially saying that any user of > any kernel infrastructure should be Cc'ed to the implementer of that > infrastructure... 9/10 patches in this series aren't even LED > > specific, I'm not saying that. I'm saying that LED maintainers should be Cced, to keep the interfaces consistent. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
custom ioctl-based interface to control LED in networking (was Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode)
On Wed 2016-02-24 10:01:49, Johannes Berg wrote: > On Tue, 2016-02-23 at 22:45 +0100, Pavel Machek wrote: > > > Well "the airplane mode" is well defined. It means no intentional > > transmitting at radio frequencies. > > > > The fact that you are allowed to use WIFI on certain flights does not > > change anything. > > Nope, not that simple. Pick up any (contemporary) smartphone and watch > what happens with the airplane mode indicator (the little airplane > icon) when you enable wifi after enabling airplane mode. It stays > there. > > Clearly the same logic could then apply to an actual LED (on a system > that's less size-constrained, e.g. a laptop or tablet.) > > Thus, the display of "in airplane mode" *does* have policy, and clearly > there's precedent for not disabling the icon or LED when wifi is > enabled, but the kernel shouldn't really impose that. Now, the kernel > has a "safe" default which does what you thought was the "well defined" > airplane mode, but at the same time it's obviously not good enough. If you want different trigger, implement different trigger. If you want to indicate all but wifi, implement all but wifi, and then userspace can select it by writing trigger name. If you want complete userspace control, fine, but we have standard interface and it is not ioctl. > > (Besides, finding all LEDs with given trigger is trivial > > operation. Besides... there should never be more than one). > > That *might* actually work. But once a tool has detached the trigger > the information is gone; and tools would have to do that to control the > LED, making recovery from any kind of error difficult. If you allow userspace to control the LED, well, then the LED may no longer display the "airplane mode" status. Debugging "wrong trigger is set" will certainly be less tricky than figuring out that "airplane mode trigger" is actually "no trigger" based on some obscure ioctls. > In any case, I've applied those patches already. Well, you can still revert them before it becomes ABI. David does not have to pull from you and Linus does not have to pull from Linus. Besides, the series really should have been Cc-ed to LED people, too. Having custom, ioctl-based interface to control the LED is just too ugly. (And I did not see it documented, which should be another reason not to merge it.) Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode
On Tue 2016-02-23 21:55:14, Johannes Berg wrote: > On Tue, 2016-02-23 at 21:45 +0100, Pavel Machek wrote: > > > So... you add LED trigger to display the state of the airplane > > mode. Ok, why not. > > Yes. However, consider that "the airplane mode" isn't a well-defined > concept; some systems may want to light up that LED even when wifi is > still enabled, since you're nowadays quite likely to be allowed to use > wifi (but not enable e.g. LTE) while in-flight. Well "the airplane mode" is well defined. It means no intentional transmitting at radio frequencies. The fact that you are allowed to use WIFI on certain flights does not change anything. > > But now you add an way to override it? Why? If someone wants to > > change > > the led state, he can just change trigger to none, and then control > > the LED manually... > > Yes, but now you've forced every application that wants to deal with > this to know about every single LED that might be used with this > trigger... that won't work for some generic userland tool that might > want to implement an "airplane-mode policy". I see that "airplane mode" trigger might be a tiny bit useful... dunno, for a LED near the airplane mode switch, when vendor replaced hardware toggle with a key. But policy should have nothing to do with that. If you argue additional "policy daemon" is needed for that... forget it, that's overdesigned. (Besides, finding all LEDs with given trigger is trivial operation. Besides... there should never be more than one). > > BTW what happens when the device contains both radios controlled by > > kernel (wifi, bluetooth) and radios controlled by userspace (GSM > > modem)? > > You'd better have the userspace to control the LED :) Yes, so lets forget that and no additional triggers? Good ;-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode
Hi! [BTW you should probably Cc people responsible for LED subsystem...] > Provide an interface for the airplane-mode indicator be controlled from > userspace. User has to first acquire the control through > RFKILL_OP_AIRPLANE_MODE_ACQUIRE and keep the fd open for the whole time > it wants to be in control of the indicator. Closing the fd or using > RFKILL_OP_AIRPLANE_MODE_RELEASE restores the default policy. > > To change state of the indicator, the RFKILL_OP_AIRPLANE_MODE_CHANGE > operation is used, passing the value on "struct rfkill_event.soft". If > the caller has not acquired the airplane-mode control beforehand, the > operation fails. So... you add LED trigger to display the state of the airplane mode. Ok, why not. But now you add an way to override it? Why? If someone wants to change the led state, he can just change trigger to none, and then control the LED manually... BTW what happens when the device contains both radios controlled by kernel (wifi, bluetooth) and radios controlled by userspace (GSM modem)? Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 04/10] rfkill: Move "state" sysfs file back to stable
On Mon 2016-02-22 11:36:35, João Paulo Rechi Vita wrote: > There is still quite a bit of code using this interface, so we can't > just remove it. Hopefully it will be possible in the future, but since > its scheduled removal date is past 2 years already, we are better having > the documentation reflecting the current state of things. Umm. If you think it is still obsolete (and you do), you should keep it in place. > -rfkill - radio frequency (RF) connector kill switch support > - > -For details to this subsystem look at Documentation/rfkill.txt. > - > -What:/sys/class/rfkill/rfkill[0-9]+/state > -Date:09-Jul-2007 > -KernelVersionv2.6.22 > -Contact: linux-wireless@vger.kernel.org > -Description: Current state of the transmitter. > - This file is deprecated and scheduled to be removed in > -2014, Change it to "and may be removed," Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Low latency communication over wifi
On Mon 2015-09-28 09:41:43, Johannes Berg wrote: > On Sat, 2015-09-26 at 12:24 +0200, Pavel Machek wrote: > > > > That would be equivalent to ping -Q, right? It does not seem to have > > any effect :-(. I'd expect at least local machine to use shorter waits > > for medium, and thus drop packets instead of waiting. > > Correct. But it won't *drop* packets, it just increases the chances of > getting medium access. Increases chances of medium access, but limits number of retries, so it should drop sooner, no? > > > # you have to add some magic for matching your data > > > e.g. $IPT -t mangle -I OUTPUT -j DSCP --set-dscp-class CS7 > > > > Again, this is ping -Q equivalent, right? I was doing > > Yes. > > > ping -c 300 -i .2 -Q $[56*4] -s 500 amd > > 300 packets transmitted, 300 received, 0% packet loss, time 60989ms > > rtt min/avg/max/mdev = 2.155/8.599/44.475/5.677 ms > > 300 packets transmitted, 300 received, +1 duplicates, 0% packet loss, time > > 61030ms > > rtt min/avg/max/mdev = 2.158/23.809/300.956/49.969 ms, pipe 2 > > > > I would expect packet loss, but got long delays instead. > > See above :) > > > > also you should consider force the ACK-timing to 450m / Class1 > > > and forbid retransmission in minstrel > > > > Yes, disabling retransmission would be useful. How would I do that? > > > It won't work on Intel devices though since they don't use > minstrel(_ht) I'm using ath5k for testing... that should use minstrel AFAICT. 02:02.0 Ethernet controller: Qualcomm Atheros AR5211 Wireless Network Adapter [AR5001X 802.11ab] (rev 01) I'm now trying: # Background load sudo ping -f amd -s 8000 # Test ping -c 30 -i .2 -Q $[0*4] -s 500 amd ping -c 30 -i .2 -Q $[40*4] -s 500 amd ping -c 30 -i .2 -Q $[56*4] -s 500 amd This should send the second ping to the priority queue based on -Q, but I don't see an effect against one access point and it seems to work somehow against second one. Good! avg/maximum latency goes from 8/24 (-Q $[40*4]) to 80/258 (same settings, every second frame is slow?!) to 8/26 to 7/32 to 6/18. But this jumps to 92/123, 95/139, 91/128 and 135/678 with (-Q 0). -Q $[56*4] produces 6/10, 8/23, 6/14, 5/9, 5/14. Good. Thanks! Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Low latency communication over wifi
Hi! > > (I could use Intel 3945ABG-based card instead, but I figured out > > ath5k might be easier to hack?) > > > > Is there way to manipulate type of service from userland to get > > similar behaviour without patching kernel? > > If your AP has WMM/QoS then you can use setsockopt(SO_PRIORITY) to > change the TID and thus the AC and get your packets classified as voice > (VO) on wifi, which makes them much more likely to get access to the > medium. That would be equivalent to ping -Q, right? It does not seem to have any effect :-(. I'd expect at least local machine to use shorter waits for medium, and thus drop packets instead of waiting. On Wed 2015-09-23 13:42:36, Bastian Bittorf wrote: > * Pavel Machek [23.09.2015 13:38]: > > Is there way to manipulate type of service from userland to get > > similar behaviour without patching kernel? > > yes, iptables DSCP / DiffServ / Differentiated Services Field > > # you have to add some magic for matching your data > e.g. $IPT -t mangle -I OUTPUT -j DSCP --set-dscp-class CS7 Again, this is ping -Q equivalent, right? I was doing ping -c 300 -i .2 -Q $[56*4] -s 500 amd 300 packets transmitted, 300 received, 0% packet loss, time 60989ms rtt min/avg/max/mdev = 2.155/8.599/44.475/5.677 ms 300 packets transmitted, 300 received, +1 duplicates, 0% packet loss, time 61030ms rtt min/avg/max/mdev = 2.158/23.809/300.956/49.969 ms, pipe 2 I would expect packet loss, but got long delays instead. > also you should consider force the ACK-timing to 450m / Class1 > and forbid retransmission in minstrel Yes, disabling retransmission would be useful. How would I do that? Thanks and best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ath5k filling logs (was Re: Low latency communication over wifi)
Hi! > I hacked qcu.c to limit latencies: > > qi->tqi_cw_min = ath5k_cw_validate(0); > qi->tqi_cw_max = ath5k_cw_validate(20); > > ...but I don't think it did what I wanted. What am I missing? > > (I could use Intel 3945ABG-based card instead, but I figured out ath5k > might be easier to hack?) Speaking of ath5k... it fills logs with lots of messages: [ 53.486222] ath5k: ath5k_hw_get_isr: ISR: 0x0400 IMR: 0x80081035 [ 61.217713] ath5k: ath5k_hw_get_isr: ISR: 0x0400 IMR: 0x80081035 Should I just delete the print from kernel, or is there something I should debug? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Low latency communication over wifi
Hi! I'm trying to transfer some audio data over wifi. Latency constrains are such that if it would took more than 20msec to wait for transmission, the packet should be dropped instead, and new one should be transmitted. My final hardware contains CSR6026 chip, but drivers are way too ugly, I decided it would be easier to prototype on ath5k-based card. I hacked qcu.c to limit latencies: qi->tqi_cw_min = ath5k_cw_validate(0); qi->tqi_cw_max = ath5k_cw_validate(20); ...but I don't think it did what I wanted. What am I missing? (I could use Intel 3945ABG-based card instead, but I figured out ath5k might be easier to hack?) Is there way to manipulate type of service from userland to get similar behaviour without patching kernel? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] wireless extensions should default to Y
On Wed 2015-01-07 11:41:55, Johannes Berg wrote: > On Wed, 2015-01-07 at 11:19 +0100, Pavel Machek wrote: > > Do we need following patch on top of > > 24a0aa212ee2dbe44360288684478d76a8e20a0a revert? > > > > I updated kernel today, and (probably because extensions were not > > selectable before), the default choice was "N", which is wrong: > > oldconfig should result in compatible choices being made, for example > > to help bisect. > > I don't believe we need this. It has been defaulting to N for a long > time, it's just that it got thrown out of your config due to building > inbetween the patch and its revert. Had you built only before and after > that wouldn't be an issue. Well, I clearly hit the issue. If someone had _not_ build in between, the "default y" does not change anything for him, as he will not be asked thequestion. If someone starts config from scratch, Y is the safe answer. > If we default to Y now we send the wrong signal. If you really need to > bisect something wext related you have far bigger issues I'd think, the > code hasn't changed *forever*. I am woried about bisecting something unrelated, and then wext coming and breaking the bisect. But you are right that it will break the bisect, anyway... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] wireless extensions should default to Y
Do we need following patch on top of 24a0aa212ee2dbe44360288684478d76a8e20a0a revert? I updated kernel today, and (probably because extensions were not selectable before), the default choice was "N", which is wrong: oldconfig should result in compatible choices being made, for example to help bisect. Signed-off-by: Pavel Machek diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig index 29c8675..8951dba 100644 --- a/net/wireless/Kconfig +++ b/net/wireless/Kconfig @@ -177,6 +177,7 @@ config CFG80211_INTERNAL_REGDB config CFG80211_WEXT bool "cfg80211 wireless extensions compatibility" depends on CFG80211 + default y select WEXT_CORE help Enable this option if you need old userspace for wireless -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"
On Wed 2014-12-31 08:49:00, Peter Hurley wrote:
> On 12/31/2014 08:26 AM, Grumbach, Emmanuel wrote:
> >>
> >> On Wed, 31 Dec 2014, Arend van Spriel wrote:
> >>
> >>> You mentioned in the discussion and I quote: "*If* wireless
> >>> maintainers think otherwise, I'll send a revert request to Linus for
> >>> consideration.". However, you did not wait for any response from the
> >>> wireless maintainers nor from the author of the patch you are reverting.
> >>> Seems like an overreaction to me though personally I do not disgree
> >>> with the revert itself.
> >>
> >> My understanding from the whole thread was that Emmanuel disagrees with
> >> the revert, and I consider Emmanuel to definitely belong to the "wireless
> >> maintainers" group. If my understanding was wrong on this, sorry for that.
> >
> > You understanding is wrong. This patch has an author and you could I didn't
> > sign-off the patch which is an obvious indication I am not a "wireless
> > maintainer".
> > You didn't even make the minimal effort to check how this patch should be
> > properly
> > routed.
> >
> > Regardless of all this, I didn't say I disagree, I said that we need to
> > find a way to signal
> > the userland developers that an API will be deprecated at some point. I
> > haven't seen
> > any response / suggestion from you on that.
>
> pr_notice_once("WEXT compatibility has been deprecated since _" \
>" Upgrade your userspace tools to nl80211!\n");
Kernel interfaces are not being removed, not now, not ever. No need to
spam logs.
(And to the person who suggested WARN(): No.)
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wl1251: NVS firmware data
On Thu 2014-11-27 07:58:40, Greg Kroah-Hartman wrote: > On Thu, Nov 27, 2014 at 04:22:58PM +0100, Pali Rohár wrote: > > On Thursday 27 November 2014 16:16:55 Greg Kroah-Hartman wrote: > > > On Thu, Nov 27, 2014 at 03:43:23PM +0100, Pali Rohár wrote: > > > > On Thursday 27 November 2014 15:21:44 Ming Lei wrote: > > > > > On Thu, Nov 27, 2014 at 10:06 PM, Pali Rohár > > > > > > > > wrote: > > > > > > Hello, > > > > > > > > > > > > wifi driver wl1251 needs NVS calibration data for > > > > > > working. These data are loaded by driver via > > > > > > request_firmware from userspace file: > > > > > > ti-connectivity/wl1251-nvs.bin. In linux-fimrware git > > > > > > tree there is generic wl1251-nvs.bin file which is used > > > > > > by default. > > > > > > > > > > > > Driver wl1251 is used on Nokia N900 cellphone for its > > > > > > wifi chip. This cellphone has one special MTD partition > > > > > > (called CAL) where are stored some configuration data > > > > > > in special binary (key-value) format. And there is also > > > > > > stored correct calibration data for specific device > > > > > > (each device has different data). It is preferred to > > > > > > use those data instead generic one (provided by > > > > > > linux-firmware git tree). > > > > > > > > > > > > Now my question is: How to correctly load calibration > > > > > > data from special Nokia N900 CAL partition into wl1251 > > > > > > kernel driver? > > > > > > > > > > It is better to let user space script handle the request. > > > > > > > > Yes, this makes sense. Implementing CAL parser in kernel > > > > wl1251 driver would be hard... > > > > > > > > > > By default kernel reads ti-connectivity/wl1251-nvs.bin > > > > > > file from VFS if exists without any userspace support. > > > > > > If it fails then it fallback to loading via udev. > > > > > > > > > > You can remove or rename this file so that loading from > > > > > user space can be triggered. > > > > > > > > It is no so easy... In case when CAL does not contains NVS > > > > data then we want to use this generic NVS file. And telling > > > > everybody to rename this is file is not good solution... > > > > > > But that's up to your system configuration, not the kernel. > > > Make a userspace package for the firmware that creates it in > > > the format you need it to be in, for the hardware you have, > > > and then there would not be any need for a kernel change, > > > right? > > > > > > greg k-h > > > > Not so simple as you think. Some parts of NVS data are configured > > based on location and cellular station. Data are not static. > > Then you need a dynamic program that you control, in userspace, to dump > the needed data into the kernel. Don't try to do it with "static" > firmware files. Use the binary sysfs file interface for this if you > want. Actually, this seems to be similar situation to fpga programming. There, it is static firmware for 90% users, but some special use cases want it more dynamic. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.18-rc0: iwlegacy failed after a while
On Sun 2014-11-02 13:25:45, Stanislaw Gruszka wrote: > On Tue, Oct 28, 2014 at 11:20:15PM +0100, Pavel Machek wrote: > > > > It can be checked by "iw dev wlan0 get power_save" . > > > > So it seems I have power save on. I guess someone enabled it for me :-). > > > > root@duo:~# iwconfig wlan0 > > wlan0 IEEE 802.11abg ESSID:off/any > > Mode:Managed Access Point: Not-Associated Tx-Power=15 dBm > > Retry short limit:7 RTS thr:off Fragment thr:off > > Encryption key:off > > Power Management:on > > > > root@duo:~# iw dev wlan0 get power_save > > Power save: on > > root@duo:~# > > Could you confirm that problem happen with power save on and do not > happen without it ? It has not happened for a while, but I was not loading wifi as heavily. But even powersave=on case needs to be fixed, right? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.18-rc0: iwlegacy failed after a while
On Sun 2014-10-26 12:05:54, Pavel Machek wrote: > On Sun 2014-10-26 11:33:15, Stanislaw Gruszka wrote: > > On Sat, Oct 25, 2014 at 01:42:46PM +0200, Pavel Machek wrote: > > > > Since 3.17 we have only 2 minor iwlegacy changes on current linus tree. > > > > If this is a regression it's probably caused by different subsystem > > > > changes, most likely by PCI changes. If this is not regression, such > > > > errors could be caused by enabling PS, but that has to be done > > > > explicitly, Pavel did you enable power_save ? > > > > > > This is running pretty standart MATE desktop, and no, I don't think I > > > enabled that. > > > > It can be checked by "iw dev wlan0 get power_save" . So it seems I have power save on. I guess someone enabled it for me :-). root@duo:~# iwconfig wlan0 wlan0 IEEE 802.11abg ESSID:off/any Mode:Managed Access Point: Not-Associated Tx-Power=15 dBm Retry short limit:7 RTS thr:off Fragment thr:off Encryption key:off Power Management:on root@duo:~# iw dev wlan0 get power_save Power save: on root@duo:~# > > More important quiestions: Is this regression, did you see this error > > before? How reproducible is this problem? > > I've never seen it before, and it only happened once after update to > 3.18-rc. Today wifi failed, again. Will reboot. dmesg is in the attachment, looks like same fail. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html delme.gz Description: application/gzip
Re: 3.18-rc0: iwlegacy failed after a while
On Sun 2014-10-26 11:33:15, Stanislaw Gruszka wrote: > On Sat, Oct 25, 2014 at 01:42:46PM +0200, Pavel Machek wrote: > > > Since 3.17 we have only 2 minor iwlegacy changes on current linus tree. > > > If this is a regression it's probably caused by different subsystem > > > changes, most likely by PCI changes. If this is not regression, such > > > errors could be caused by enabling PS, but that has to be done > > > explicitly, Pavel did you enable power_save ? > > > > This is running pretty standart MATE desktop, and no, I don't think I > > enabled that. > > It can be checked by "iw dev wlan0 get power_save" . > > More important quiestions: Is this regression, did you see this error > before? How reproducible is this problem? I've never seen it before, and it only happened once after update to 3.18-rc. > There is this message in the dmesg: > > iwl3945 :03:00.0: BSM uCode verification failed at addr 0x3800+0 (of > 900), is 0xa5a5a5a2, s/b 0xf802020 > > 0xa5a5a5a2 value suggest that we disconnect from the PCI bus, hence > this could be also a H/W problem. That machine is 10 years old and will work for another 10. It does not have h/w problems ;-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.18-rc0: iwlegacy failed after a while
On Fri 2014-10-24 14:12:40, Stanislaw Gruszka wrote: > On Thu, Oct 23, 2014 at 01:02:37PM +, Grumbach, Emmanuel wrote: > > [Changed subject] > > This is really iwlegacy and not iwlwifi. > > > > > > > > > > Hi! > > > > > > Full dmesg is in the attachment, I guess the troubles started with: > > > > > > iwl3945 :03:00.0: Queue 4 stuck for 2004 ms. > > > iwl3945 :03:00.0: On demand firmware reload > > > iwl3945 :03:00.0: Master Disable Timed Out, 100 usec > > > ieee80211 phy0: Hardware restart was requested > > > iwl3945 :03:00.0: BSM uCode verification failed at addr > > > 0x3800+0 (of 900), is 0xa5\ > > > a5a5a2, s/b 0xf802020 > > > iwl3945 :03:00.0: Unable to set up bootstrap uCode: -5 > > > > > > > Huh - I don't remember any change there, but you should ask the right > > person - iwlegacy maintainer :) > > Since 3.17 we have only 2 minor iwlegacy changes on current linus tree. > If this is a regression it's probably caused by different subsystem > changes, most likely by PCI changes. If this is not regression, such > errors could be caused by enabling PS, but that has to be done > explicitly, Pavel did you enable power_save ? This is running pretty standart MATE desktop, and no, I don't think I enabled that. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
3.18-rc0: iwlwifi failed after a while
Hi! Full dmesg is in the attachment, I guess the troubles started with: iwl3945 :03:00.0: Queue 4 stuck for 2004 ms. iwl3945 :03:00.0: On demand firmware reload iwl3945 :03:00.0: Master Disable Timed Out, 100 usec ieee80211 phy0: Hardware restart was requested iwl3945 :03:00.0: BSM uCode verification failed at addr 0x3800+0 (of 900), is 0xa5\ a5a5a2, s/b 0xf802020 iwl3945 :03:00.0: Unable to set up bootstrap uCode: -5 Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html delme.gz Description: application/gzip
