* Re: [PATCH] sony-laptop: check for rfkill hard block at load time
From: Alan Jenkins @ 2009-09-24 20:11 UTC (permalink / raw)
To: Gábor Stefanik
Cc: Mattia Dongili, linux-wireless@vger.kernel.org, Norbert Preining,
Johannes Berg, Almer S. Tigelaar, Matthias Welwarsky
In-Reply-To: <69e28c910909241224q10202a47o37ba0f3975ee3294@mail.gmail.com>
Gábor Stefanik wrote:
> On Thu, Sep 24, 2009 at 9:15 PM, Alan Jenkins
> <alan-jenkins@tuffmail.co.uk> wrote:
>
>> "I recently (on a flight) I found out that when I boot with the hard-switch
>> activated, so turning off all wireless activity on my laptop, the state
>> is not correctly announced in /dev/rfkill (reading it with rfkill command,
>> or my own gnome applet)...
>>
>> After turning off and on again the hard-switch the events were right."
>>
>> We can fix this by querying the firmware at load time and calling
>> rfkill_set_hw_state().
>>
>> Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
>> Tested-by: Norbert Preining <preining@logic.at>
>> ---
>> drivers/platform/x86/sony-laptop.c | 6 ++++++
>> 1 files changed, 6 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/platform/x86/sony-laptop.c b/drivers/platform/x86/sony-laptop.c
>> index dafaa4a..a234a9d 100644
>> --- a/drivers/platform/x86/sony-laptop.c
>> +++ b/drivers/platform/x86/sony-laptop.c
>> @@ -1081,6 +1081,8 @@ static int sony_nc_setup_rfkill(struct acpi_device *device,
>> struct rfkill *rfk;
>> enum rfkill_type type;
>> const char *name;
>> + int result;
>> + bool hwblock;
>>
>> switch (nc_type) {
>> case SONY_WIFI:
>> @@ -1108,6 +1110,10 @@ static int sony_nc_setup_rfkill(struct acpi_device *device,
>> if (!rfk)
>> return -ENOMEM;
>>
>> + sony_call_snc_handle(0x124, 0x200, &result);
>>
>
> Please define these somewhere, don't use magic numbers.
>
The rfkill functions are all together in the file, it's not that bad.
But ok.
There's another bug / missing feature - it doesn't re-read the hard
states on resume from suspend.
I'll submit two more patches then. I won't convert all of the magic
numbers though. This isn't hardware I know anything about, and "magic
numbers" is a good description of some of them -
/* Setup hotkeys */
sony_call_snc_handle(0x0100, 0, &result);
sony_call_snc_handle(0x0101, 0, &result);
sony_call_snc_handle(0x0102, 0x100, &result);
sony_call_snc_handle(0x0127, 0, &result);
Others are already sufficiently obvious, and the extra indirection would
only serve to obscure
/* Enable all events */
acpi_callsetfunc(sony_nc_acpi_handle, "SN02", 0xffff, &result);
^ permalink raw reply
* Re: [PATCH 1/2] cfg80211: add firmware and hardware version to wiphy
From: Luis R. Rodriguez @ 2009-09-24 20:08 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <da94abde0909241214y8179cfeoa86aa59346daa9ef@mail.gmail.com>
On Thu, Sep 24, 2009 at 12:14 PM, Kalle Valo <kalle.valo@iki.fi> wrote:
> The length is used four time so I would not want to remove it. Maybe
> rename to CFG80211_FWHW_VERSION_LEN?
Sure.
Luis
^ permalink raw reply
* Re: Disassociating atheros wlan with 2.6.31
From: Justin P. Mattock @ 2009-09-24 20:07 UTC (permalink / raw)
To: Stefan Lippers-Hollmann
Cc: linux-wireless, Kristoffer Ericson, linux-kernel@vger.kernel.org
In-Reply-To: <200909242155.49890.s.L-H@gmx.de>
Stefan Lippers-Hollmann wrote:
> Hi
>
> CCing linux-wireless@vger.kernel.org, as it's not very likely to get
> noticed here by wireless developers.
>
> On Thursday 24 September 2009, Justin P. Mattock wrote:
>
>> Kristoffer Ericson wrote:
>>
>>> Greetings,
>>>
>>> When moving from vanilla 2.6.30->2.6.31 I noticed that I get dissasociated from
>>> my wlan hub with regular intervalls. This did not happen on 2.6.30.
>>> I cant see any pattern aside from that it happens at regular intervalls
>>> (around 10-15mins). It works again when I re-identifies myself.
>>>
>>> Got an Asus 1000HE with Atheros chipset.
>>> Havent had time to bisect it, just wanted to check
>>> if this is an known issue. Ive ruled out faulty wlan hub
>>> since everything works fine when going back to 2.6.30.
>>>
>>> nothing much on dmesg:
>>> uhci_hcd 0000:00:1d.1: UHCI Host Controller
>>> uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
>>> uhci_hcd 0000:00:1d.1: irq 19, io base 0x0000d480
>>> usb usb3: configuration #1 chosen from 1 choice
>>> hub 3-0:1.0: USB hub found
>>> hub 3-0:1.0: 2 ports detected
>>> uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
>>> uhci_hcd 0000:00:1d.2: setting latency timer to 64
>>> uhci_hcd 0000:00:1d.2: UHCI Host Controller
>>> uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
>>> uhci_hcd 0000:00:1d.2: irq 18, io base 0x0000d800
>>> usb usb4: configuration #1 chosen from 1 choice
>>> hub 4-0:1.0: USB hub found
>>> hub 4-0:1.0: 2 ports detected
>>> uhci_hcd 0000:00:1d.3: PCI INT D -> GSI 16 (level, low) -> IRQ 16
>>> uhci_hcd 0000:00:1d.3: setting latency timer to 64
>>> uhci_hcd 0000:00:1d.3: UHCI Host Controller
>>> uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
>>> uhci_hcd 0000:00:1d.3: irq 16, io base 0x0000d880
>>> usb usb5: configuration #1 chosen from 1 choice
>>> hub 5-0:1.0: USB hub found
>>> hub 5-0:1.0: 2 ports detected
>>> input: ETPS/2 Elantech Touchpad as /devices/platform/i8042/serio1/input/input7
>>> usb 1-4: new high speed USB device using ehci_hcd and address 3
>>> usb 1-4: configuration #1 chosen from 1 choice
>>> hub 1-4:1.0: USB hub found
>>> hub 1-4:1.0: 4 ports detected
>>> usb 1-5: new high speed USB device using ehci_hcd and address 4
>>> usb 1-5: configuration #1 chosen from 1 choice
>>> usb 1-8: new high speed USB device using ehci_hcd and address 6
>>> usb 1-8: configuration #1 chosen from 1 choice
>>> Initializing USB Mass Storage driver...
>>> scsi4 : SCSI emulation for USB Mass Storage devices
>>> usbcore: registered new interface driver usb-storage
>>> USB Mass Storage support registered.
>>> usb-storage: device found at 4
>>> usb-storage: waiting for device to settle before scanning
>>> HDA Intel 0000:00:1b.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
>>> HDA Intel 0000:00:1b.0: setting latency timer to 64
>>> usb 2-2: new full speed USB device using uhci_hcd and address 2
>>> ath9k 0000:01:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
>>> ath9k 0000:01:00.0: setting latency timer to 64
>>> usb 2-2: configuration #1 chosen from 1 choice
>>> input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1b.0/input/input8
>>> usbcore: registered new interface driver usbserial
>>> USB Serial support registered for generic
>>> usb 5-1: new full speed USB device using uhci_hcd and address 2
>>> usb 5-1: configuration #1 chosen from 1 choice
>>> usb 1-4.1: new full speed USB device using ehci_hcd and address 7
>>> ath: EEPROM regdomain: 0x60
>>> ath: EEPROM indicates we should expect a direct regpair map
>>> ath: Country alpha2 being used: 00
>>> ath: Regpair used: 0x60
>>> Bluetooth: Core ver 2.15
>>> NET: Registered protocol family 31
>>> Bluetooth: HCI device and connection manager initialized
>>> Bluetooth: HCI socket layer initialized
>>> Bluetooth: Generic Bluetooth USB driver ver 0.5
>>> usb 1-4.1: configuration #1 chosen from 1 choice
>>> usb 1-4.2: new low speed USB device using ehci_hcd and address 8
>>> usb 1-4.2: configuration #1 chosen from 1 choice
>>> usb 1-4.4: new low speed USB device using ehci_hcd and address 9
>>> usbcore: registered new interface driver hiddev
>>> input: HID 04d9:1203 as /devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.2/1-4.2:1.0/input/input9
>>> generic-usb 0003:04D9:1203.0001: input,hidraw0: USB HID v1.11 Keyboard [HID 04d9:1203] on usb-0000:00:1d.7-4.2/input0
>>> input: HID 04d9:1203 as /devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.2/1-4.2:1.1/input/input10
>>> generic-usb 0003:04D9:1203.0002: input,hidraw1: USB HID v1.11 Device [HID 04d9:1203] on usb-0000:00:1d.7-4.2/input1
>>> usbcore: registered new interface driver usbhid
>>> usbhid: v2.6:USB HID core driver
>>> usb 1-4.4: configuration #1 chosen from 1 choice
>>> input: B16_b_02 USB-PS/2 Optical Mouse as /devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.4/1-4.4:1.0/input/input11
>>> generic-usb 0003:046D:C025.0003: input,hidraw2: USB HID v1.10 Mouse [B16_b_02 USB-PS/2 Optical Mouse] on usb-0000:00:1d.7-4.4/input0
>>> usbcore: registered new interface driver btusb
>>> usbcore: registered new interface driver usbserial_generic
>>> usbserial: USB Serial Driver core
>>> USB Serial support registered for GSM modem (1-port)
>>> option 2-2:1.0: GSM modem (1-port) converter detected
>>> usb 2-2: GSM modem (1-port) converter now attached to ttyUSB0
>>> option 2-2:1.1: GSM modem (1-port) converter detected
>>> usb 2-2: GSM modem (1-port) converter now attached to ttyUSB1
>>> usbcore: registered new interface driver option
>>> option: v0.7.2:USB Driver for GSM modems
>>> USB Serial support registered for pl2303
>>> pl2303 1-4.1:1.0: pl2303 converter detected
>>> usb 1-4.1: pl2303 converter now attached to ttyUSB2
>>> usbcore: registered new interface driver pl2303
>>> pl2303: Prolific PL2303 USB to serial adaptor driver
>>> phy0: Selected rate control algorithm 'ath9k_rate_control'
>>> Registered led device: ath9k-phy0::radio
>>> Registered led device: ath9k-phy0::assoc
>>> Registered led device: ath9k-phy0::tx
>>> Registered led device: ath9k-phy0::rx
>>> phy0: Atheros AR9280 MAC/BB Rev:2 AR5133 RF Rev:d0: mem=0xf8880000, irq=19
>>> scsi 4:0:0:0: Direct-Access Single Flash Reader 1.00 PQ: 0 ANSI: 0
>>> sd 4:0:0:0: Attached scsi generic sg1 type 0
>>> sd 4:0:0:0: [sdb] 15954944 512-byte logical blocks: (8.16 GB/7.60 GiB)
>>> usb-storage: device scan complete
>>> sd 4:0:0:0: [sdb] Write Protect is off
>>> sd 4:0:0:0: [sdb] Mode Sense: 03 00 00 00
>>> sd 4:0:0:0: [sdb] Assuming drive cache: write through
>>> sd 4:0:0:0: [sdb] Assuming drive cache: write through
>>> sdb: sdb1
>>> sd 4:0:0:0: [sdb] Assuming drive cache: write through
>>> sd 4:0:0:0: [sdb] Attached SCSI removable disk
>>> EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
>>> EXT3 FS on sda1, internal journal
>>> Bluetooth: L2CAP ver 2.13
>>> Bluetooth: L2CAP socket layer initialized
>>> Bluetooth: SCO (Voice Link) ver 0.6
>>> Bluetooth: SCO socket layer initialized
>>> Bluetooth: BNEP (Ethernet Emulation) ver 1.3
>>> Bridge firewalling registered
>>> Bluetooth: RFCOMM TTY layer initialized
>>> Bluetooth: RFCOMM socket layer initialized
>>> Bluetooth: RFCOMM ver 1.11
>>> ATL1E 0000:03:00.0: irq 27 for MSI/MSI-X
>>> fuse init (API version 7.12)
>>> ip_tables: (C) 2000-2006 Netfilter Core Team
>>> nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
>>> CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use
>>> nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option or
>>> sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
>>> wlan0: authenticate with AP 00:14:7c:ae:d1:90
>>> wlan0: authenticated
>>> wlan0: associate with AP 00:14:7c:ae:d1:90
>>> wlan0: RX AssocResp from 00:14:7c:ae:d1:90 (capab=0x431 status=0 aid=5)
>>> wlan0: associated
>>> PPP generic driver version 2.4.2
>>> NET: Registered protocol family 10
>>> lo: Disabled Privacy Extensions
>>> ADDRCONF(NETDEV_UP): eth0: link is not ready
>>> PPP BSD Compression module registered
>>> PPP Deflate Compression module registered
>>> wlan0: no IPv6 routers present
>>> CE: hpet increasing min_delta_ns to 15000 nsec
>>> wlan0: no probe response from AP 00:14:7c:ae:d1:90 - disassociating
>>> wlan0: authenticate with AP 00:14:7c:ae:d1:90
>>> wlan0: authenticated
>>> wlan0: associate with AP 00:14:7c:ae:d1:90
>>> wlan0: RX AssocResp from 00:14:7c:ae:d1:90 (capab=0x431 status=0 aid=5)
>>> wlan0: associated
>>> wlan0: authenticate with AP 00:14:7c:ae:d1:90
>>> wlan0: authenticated
>>> wlan0: associate with AP 00:14:7c:ae:d1:90
>>> wlan0: RX AssocResp from 00:14:7c:ae:d1:90 (capab=0x431 status=0 aid=5)
>>> wlan0: associated
>>> [kristoffer@boggieman wine.git]$
>>>
>>>
>>>
>>>
>> yeah I'm seeing this with my macbook pro(ath9k)
>> while streaming music, all of a sudden things just crap out.
>> (not sure if this is why, or something else).
>>
>> Justin P. Mattock
>>
>
> I'm getting similar reports for iwl3945 and 2.6.31.[01], but can't confirm
> this on my own (non-iwl{3945,agn}, non-ath9k) hardware yet.
>
> Regards
> Stefan Lippers-Hollmann
>
>
I don't mind doing a bisect from 30 - present, but first I need to
do some other stuff.
Justin P. Mattock
^ permalink raw reply
* Re: Disassociating atheros wlan with 2.6.31
From: Stefan Lippers-Hollmann @ 2009-09-24 19:55 UTC (permalink / raw)
To: linux-wireless
Cc: Justin P. Mattock, Kristoffer Ericson,
linux-kernel@vger.kernel.org
In-Reply-To: <4ABBB9D3.4020200@gmail.com>
Hi
CCing linux-wireless@vger.kernel.org, as it's not very likely to get
noticed here by wireless developers.
On Thursday 24 September 2009, Justin P. Mattock wrote:
> Kristoffer Ericson wrote:
> > Greetings,
> >
> > When moving from vanilla 2.6.30->2.6.31 I noticed that I get dissasociated from
> > my wlan hub with regular intervalls. This did not happen on 2.6.30.
> > I cant see any pattern aside from that it happens at regular intervalls
> > (around 10-15mins). It works again when I re-identifies myself.
> >
> > Got an Asus 1000HE with Atheros chipset.
> > Havent had time to bisect it, just wanted to check
> > if this is an known issue. Ive ruled out faulty wlan hub
> > since everything works fine when going back to 2.6.30.
> >
> > nothing much on dmesg:
> > uhci_hcd 0000:00:1d.1: UHCI Host Controller
> > uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
> > uhci_hcd 0000:00:1d.1: irq 19, io base 0x0000d480
> > usb usb3: configuration #1 chosen from 1 choice
> > hub 3-0:1.0: USB hub found
> > hub 3-0:1.0: 2 ports detected
> > uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
> > uhci_hcd 0000:00:1d.2: setting latency timer to 64
> > uhci_hcd 0000:00:1d.2: UHCI Host Controller
> > uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
> > uhci_hcd 0000:00:1d.2: irq 18, io base 0x0000d800
> > usb usb4: configuration #1 chosen from 1 choice
> > hub 4-0:1.0: USB hub found
> > hub 4-0:1.0: 2 ports detected
> > uhci_hcd 0000:00:1d.3: PCI INT D -> GSI 16 (level, low) -> IRQ 16
> > uhci_hcd 0000:00:1d.3: setting latency timer to 64
> > uhci_hcd 0000:00:1d.3: UHCI Host Controller
> > uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
> > uhci_hcd 0000:00:1d.3: irq 16, io base 0x0000d880
> > usb usb5: configuration #1 chosen from 1 choice
> > hub 5-0:1.0: USB hub found
> > hub 5-0:1.0: 2 ports detected
> > input: ETPS/2 Elantech Touchpad as /devices/platform/i8042/serio1/input/input7
> > usb 1-4: new high speed USB device using ehci_hcd and address 3
> > usb 1-4: configuration #1 chosen from 1 choice
> > hub 1-4:1.0: USB hub found
> > hub 1-4:1.0: 4 ports detected
> > usb 1-5: new high speed USB device using ehci_hcd and address 4
> > usb 1-5: configuration #1 chosen from 1 choice
> > usb 1-8: new high speed USB device using ehci_hcd and address 6
> > usb 1-8: configuration #1 chosen from 1 choice
> > Initializing USB Mass Storage driver...
> > scsi4 : SCSI emulation for USB Mass Storage devices
> > usbcore: registered new interface driver usb-storage
> > USB Mass Storage support registered.
> > usb-storage: device found at 4
> > usb-storage: waiting for device to settle before scanning
> > HDA Intel 0000:00:1b.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> > HDA Intel 0000:00:1b.0: setting latency timer to 64
> > usb 2-2: new full speed USB device using uhci_hcd and address 2
> > ath9k 0000:01:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
> > ath9k 0000:01:00.0: setting latency timer to 64
> > usb 2-2: configuration #1 chosen from 1 choice
> > input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1b.0/input/input8
> > usbcore: registered new interface driver usbserial
> > USB Serial support registered for generic
> > usb 5-1: new full speed USB device using uhci_hcd and address 2
> > usb 5-1: configuration #1 chosen from 1 choice
> > usb 1-4.1: new full speed USB device using ehci_hcd and address 7
> > ath: EEPROM regdomain: 0x60
> > ath: EEPROM indicates we should expect a direct regpair map
> > ath: Country alpha2 being used: 00
> > ath: Regpair used: 0x60
> > Bluetooth: Core ver 2.15
> > NET: Registered protocol family 31
> > Bluetooth: HCI device and connection manager initialized
> > Bluetooth: HCI socket layer initialized
> > Bluetooth: Generic Bluetooth USB driver ver 0.5
> > usb 1-4.1: configuration #1 chosen from 1 choice
> > usb 1-4.2: new low speed USB device using ehci_hcd and address 8
> > usb 1-4.2: configuration #1 chosen from 1 choice
> > usb 1-4.4: new low speed USB device using ehci_hcd and address 9
> > usbcore: registered new interface driver hiddev
> > input: HID 04d9:1203 as /devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.2/1-4.2:1.0/input/input9
> > generic-usb 0003:04D9:1203.0001: input,hidraw0: USB HID v1.11 Keyboard [HID 04d9:1203] on usb-0000:00:1d.7-4.2/input0
> > input: HID 04d9:1203 as /devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.2/1-4.2:1.1/input/input10
> > generic-usb 0003:04D9:1203.0002: input,hidraw1: USB HID v1.11 Device [HID 04d9:1203] on usb-0000:00:1d.7-4.2/input1
> > usbcore: registered new interface driver usbhid
> > usbhid: v2.6:USB HID core driver
> > usb 1-4.4: configuration #1 chosen from 1 choice
> > input: B16_b_02 USB-PS/2 Optical Mouse as /devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.4/1-4.4:1.0/input/input11
> > generic-usb 0003:046D:C025.0003: input,hidraw2: USB HID v1.10 Mouse [B16_b_02 USB-PS/2 Optical Mouse] on usb-0000:00:1d.7-4.4/input0
> > usbcore: registered new interface driver btusb
> > usbcore: registered new interface driver usbserial_generic
> > usbserial: USB Serial Driver core
> > USB Serial support registered for GSM modem (1-port)
> > option 2-2:1.0: GSM modem (1-port) converter detected
> > usb 2-2: GSM modem (1-port) converter now attached to ttyUSB0
> > option 2-2:1.1: GSM modem (1-port) converter detected
> > usb 2-2: GSM modem (1-port) converter now attached to ttyUSB1
> > usbcore: registered new interface driver option
> > option: v0.7.2:USB Driver for GSM modems
> > USB Serial support registered for pl2303
> > pl2303 1-4.1:1.0: pl2303 converter detected
> > usb 1-4.1: pl2303 converter now attached to ttyUSB2
> > usbcore: registered new interface driver pl2303
> > pl2303: Prolific PL2303 USB to serial adaptor driver
> > phy0: Selected rate control algorithm 'ath9k_rate_control'
> > Registered led device: ath9k-phy0::radio
> > Registered led device: ath9k-phy0::assoc
> > Registered led device: ath9k-phy0::tx
> > Registered led device: ath9k-phy0::rx
> > phy0: Atheros AR9280 MAC/BB Rev:2 AR5133 RF Rev:d0: mem=0xf8880000, irq=19
> > scsi 4:0:0:0: Direct-Access Single Flash Reader 1.00 PQ: 0 ANSI: 0
> > sd 4:0:0:0: Attached scsi generic sg1 type 0
> > sd 4:0:0:0: [sdb] 15954944 512-byte logical blocks: (8.16 GB/7.60 GiB)
> > usb-storage: device scan complete
> > sd 4:0:0:0: [sdb] Write Protect is off
> > sd 4:0:0:0: [sdb] Mode Sense: 03 00 00 00
> > sd 4:0:0:0: [sdb] Assuming drive cache: write through
> > sd 4:0:0:0: [sdb] Assuming drive cache: write through
> > sdb: sdb1
> > sd 4:0:0:0: [sdb] Assuming drive cache: write through
> > sd 4:0:0:0: [sdb] Attached SCSI removable disk
> > EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
> > EXT3 FS on sda1, internal journal
> > Bluetooth: L2CAP ver 2.13
> > Bluetooth: L2CAP socket layer initialized
> > Bluetooth: SCO (Voice Link) ver 0.6
> > Bluetooth: SCO socket layer initialized
> > Bluetooth: BNEP (Ethernet Emulation) ver 1.3
> > Bridge firewalling registered
> > Bluetooth: RFCOMM TTY layer initialized
> > Bluetooth: RFCOMM socket layer initialized
> > Bluetooth: RFCOMM ver 1.11
> > ATL1E 0000:03:00.0: irq 27 for MSI/MSI-X
> > fuse init (API version 7.12)
> > ip_tables: (C) 2000-2006 Netfilter Core Team
> > nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
> > CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use
> > nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option or
> > sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
> > wlan0: authenticate with AP 00:14:7c:ae:d1:90
> > wlan0: authenticated
> > wlan0: associate with AP 00:14:7c:ae:d1:90
> > wlan0: RX AssocResp from 00:14:7c:ae:d1:90 (capab=0x431 status=0 aid=5)
> > wlan0: associated
> > PPP generic driver version 2.4.2
> > NET: Registered protocol family 10
> > lo: Disabled Privacy Extensions
> > ADDRCONF(NETDEV_UP): eth0: link is not ready
> > PPP BSD Compression module registered
> > PPP Deflate Compression module registered
> > wlan0: no IPv6 routers present
> > CE: hpet increasing min_delta_ns to 15000 nsec
> > wlan0: no probe response from AP 00:14:7c:ae:d1:90 - disassociating
> > wlan0: authenticate with AP 00:14:7c:ae:d1:90
> > wlan0: authenticated
> > wlan0: associate with AP 00:14:7c:ae:d1:90
> > wlan0: RX AssocResp from 00:14:7c:ae:d1:90 (capab=0x431 status=0 aid=5)
> > wlan0: associated
> > wlan0: authenticate with AP 00:14:7c:ae:d1:90
> > wlan0: authenticated
> > wlan0: associate with AP 00:14:7c:ae:d1:90
> > wlan0: RX AssocResp from 00:14:7c:ae:d1:90 (capab=0x431 status=0 aid=5)
> > wlan0: associated
> > [kristoffer@boggieman wine.git]$
> >
> >
> >
> yeah I'm seeing this with my macbook pro(ath9k)
> while streaming music, all of a sudden things just crap out.
> (not sure if this is why, or something else).
>
> Justin P. Mattock
I'm getting similar reports for iwl3945 and 2.6.31.[01], but can't confirm
this on my own (non-iwl{3945,agn}, non-ath9k) hardware yet.
Regards
Stefan Lippers-Hollmann
^ permalink raw reply
* ar9170 makes machine hang when shut down
From: Malte Gell @ 2009-09-24 19:55 UTC (permalink / raw)
To: linux-wireless
Hello,
I use the compat 2.6.30 and the ar9170 driver for my Netgear WN111 USB stick.
I use the packages from
http://download.opensuse.org/repositories/driver:/wireless/11.1-update/i586/
for openSUSE 11.1.
When I shutdown my machine, it hangs after the last messages "system now
rebooting" or similar.
Does it make sense to use "rmmod --force ar9170" to force removing that module
before shutting down?
Thanx
Malte
^ permalink raw reply
* Re: 2.6.31-git wireless broken
From: Hugh Dickins @ 2009-09-24 19:45 UTC (permalink / raw)
To: Johannes Berg; +Cc: John W. Linville, Rafael J. Wysocki, linux-wireless
In-Reply-To: <1253816614.3868.406.camel@johannes.local>
On Thu, 24 Sep 2009, Johannes Berg wrote:
>
> Ah. That patch isn't in yet I guess. I wonder if that could still be an
> issue though. Maybe you can try that patch along with this one:
>
> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commitdiff_plain;h=55a00b83339f25d2979b85ab6e2151390327db80;hp=cfa53f1e753ed709f0a483fa8bd16bc7d08d402d
I've now tried recent Linus -git plus both those patches on both machines,
but no joy on either.
>
> Anyhow, I'm grasping at straws -- can you tell me more about the failure
> mode, and possibly enable CONFIG_MAC80211_DEBUG_MENU and
> CONFIG_MAC80211_VERBOSE_DEBUG?
I enabled those on both machines for that trial, will keep them on for now.
The failure mode is that iwconfig says ESSID:off/any instead of showing
my essid, and I've no connectivity; but you probably need something more
specific than that.
I'll send you privately the .config of each machine, and the dmesg of
each machine, from that trial. I've just compared the .configs against
what works for 2.6.31, and everything relevant still seems to be there.
I do wonder if this is an openSUSE interaction, whether another distro
with the same kernel would be fine.
Hugh
^ permalink raw reply
* Re: [PATCH] sony-laptop: check for rfkill hard block at load time
From: Johannes Berg @ 2009-09-24 19:27 UTC (permalink / raw)
To: Alan Jenkins
Cc: Mattia Dongili, linux-wireless@vger.kernel.org, Norbert Preining,
Almer S. Tigelaar, Matthias Welwarsky
In-Reply-To: <4ABBC54C.5010103@tuffmail.co.uk>
[-- Attachment #1: Type: text/plain, Size: 1602 bytes --]
On Thu, 2009-09-24 at 20:15 +0100, Alan Jenkins wrote:
> "I recently (on a flight) I found out that when I boot with the hard-switch
> activated, so turning off all wireless activity on my laptop, the state
> is not correctly announced in /dev/rfkill (reading it with rfkill command,
> or my own gnome applet)...
>
> After turning off and on again the hard-switch the events were right."
>
> We can fix this by querying the firmware at load time and calling
> rfkill_set_hw_state().
>
> Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
> Tested-by: Norbert Preining <preining@logic.at>
Looks good, thanks Alan.
Acked-by: Johannes Berg <johannes@sipsolutions.net>
> ---
> drivers/platform/x86/sony-laptop.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/platform/x86/sony-laptop.c b/drivers/platform/x86/sony-laptop.c
> index dafaa4a..a234a9d 100644
> --- a/drivers/platform/x86/sony-laptop.c
> +++ b/drivers/platform/x86/sony-laptop.c
> @@ -1081,6 +1081,8 @@ static int sony_nc_setup_rfkill(struct acpi_device *device,
> struct rfkill *rfk;
> enum rfkill_type type;
> const char *name;
> + int result;
> + bool hwblock;
>
> switch (nc_type) {
> case SONY_WIFI:
> @@ -1108,6 +1110,10 @@ static int sony_nc_setup_rfkill(struct acpi_device *device,
> if (!rfk)
> return -ENOMEM;
>
> + sony_call_snc_handle(0x124, 0x200, &result);
> + hwblock = !(result & 0x1);
> + rfkill_set_hw_state(rfk, hwblock);
> +
> err = rfkill_register(rfk);
> if (err) {
> rfkill_destroy(rfk);
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] sony-laptop: check for rfkill hard block at load time
From: Gábor Stefanik @ 2009-09-24 19:24 UTC (permalink / raw)
To: Alan Jenkins
Cc: Mattia Dongili, linux-wireless@vger.kernel.org, Norbert Preining,
Johannes Berg, Almer S. Tigelaar, Matthias Welwarsky
In-Reply-To: <4ABBC54C.5010103@tuffmail.co.uk>
On Thu, Sep 24, 2009 at 9:15 PM, Alan Jenkins
<alan-jenkins@tuffmail.co.uk> wrote:
> "I recently (on a flight) I found out that when I boot with the hard-switch
> activated, so turning off all wireless activity on my laptop, the state
> is not correctly announced in /dev/rfkill (reading it with rfkill command,
> or my own gnome applet)...
>
> After turning off and on again the hard-switch the events were right."
>
> We can fix this by querying the firmware at load time and calling
> rfkill_set_hw_state().
>
> Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
> Tested-by: Norbert Preining <preining@logic.at>
> ---
> drivers/platform/x86/sony-laptop.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/platform/x86/sony-laptop.c b/drivers/platform/x86/sony-laptop.c
> index dafaa4a..a234a9d 100644
> --- a/drivers/platform/x86/sony-laptop.c
> +++ b/drivers/platform/x86/sony-laptop.c
> @@ -1081,6 +1081,8 @@ static int sony_nc_setup_rfkill(struct acpi_device *device,
> struct rfkill *rfk;
> enum rfkill_type type;
> const char *name;
> + int result;
> + bool hwblock;
>
> switch (nc_type) {
> case SONY_WIFI:
> @@ -1108,6 +1110,10 @@ static int sony_nc_setup_rfkill(struct acpi_device *device,
> if (!rfk)
> return -ENOMEM;
>
> + sony_call_snc_handle(0x124, 0x200, &result);
Please define these somewhere, don't use magic numbers.
> + hwblock = !(result & 0x1);
> + rfkill_set_hw_state(rfk, hwblock);
> +
> err = rfkill_register(rfk);
> if (err) {
> rfkill_destroy(rfk);
> --
> 1.6.3.2
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* [PATCH] sony-laptop: check for rfkill hard block at load time
From: Alan Jenkins @ 2009-09-24 19:15 UTC (permalink / raw)
To: Mattia Dongili
Cc: linux-wireless@vger.kernel.org, Norbert Preining, Johannes Berg,
Almer S. Tigelaar, Matthias Welwarsky
In-Reply-To: <1253813371.3868.313.camel@johannes.local>
"I recently (on a flight) I found out that when I boot with the hard-switch
activated, so turning off all wireless activity on my laptop, the state
is not correctly announced in /dev/rfkill (reading it with rfkill command,
or my own gnome applet)...
After turning off and on again the hard-switch the events were right."
We can fix this by querying the firmware at load time and calling
rfkill_set_hw_state().
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Tested-by: Norbert Preining <preining@logic.at>
---
drivers/platform/x86/sony-laptop.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/platform/x86/sony-laptop.c b/drivers/platform/x86/sony-laptop.c
index dafaa4a..a234a9d 100644
--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -1081,6 +1081,8 @@ static int sony_nc_setup_rfkill(struct acpi_device *device,
struct rfkill *rfk;
enum rfkill_type type;
const char *name;
+ int result;
+ bool hwblock;
switch (nc_type) {
case SONY_WIFI:
@@ -1108,6 +1110,10 @@ static int sony_nc_setup_rfkill(struct acpi_device *device,
if (!rfk)
return -ENOMEM;
+ sony_call_snc_handle(0x124, 0x200, &result);
+ hwblock = !(result & 0x1);
+ rfkill_set_hw_state(rfk, hwblock);
+
err = rfkill_register(rfk);
if (err) {
rfkill_destroy(rfk);
--
1.6.3.2
^ permalink raw reply related
* Re: [PATCH 1/2] cfg80211: add firmware and hardware version to wiphy
From: Kalle Valo @ 2009-09-24 19:14 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <43e72e890909241132r2c684de2i9e80537bc3d13c63@mail.gmail.com>
On Thu, Sep 24, 2009 at 11:32 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Thu, Sep 24, 2009 at 11:02 AM, Kalle Valo <kalle.valo@iki.fi> wrote:
>> From: Kalle Valo <kalle.valo@nokia.com>
>>
>> It's useful to provide firmware and hardware version to user space and have a
>> generic interface to retrieve them. Users can provide the version information
>> in bug reports etc.
>>
>> Add fields for firmware and hardware version to struct wiphy and return
>> them to user space in NL80211_CMD_GET_WIPHY reply.
>
> Wow that was quick :)
Yeah, it's easy to hack here at Plumbers :D
>> NL80211_ATTR_PID,
>>
>> + NL80211_ATTR_FW_VERSION,
>> + NL80211_ATTR_HW_VERSION,
>> +
>
> Some kdoc on this would be nice.
Definitely. I'll add it in v2 if the implementation is ok otherwise.
>> /* add attributes here, update the policy in nl80211.c */
>>
>> __NL80211_ATTR_AFTER_LAST,
>> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
>> index 3d874c6..de3da19 100644
>> --- a/include/net/cfg80211.h
>> +++ b/include/net/cfg80211.h
>> @@ -1070,6 +1070,8 @@ struct cfg80211_ops {
>> * and registration/helper functions
>> */
>>
>> +#define CFG80211_VERSION_LEN 32
>
> Probably best to just remove this or at least make this not just
> CFG80211_VERSION_LEN, seems like this is related to cfg80211's version
> somehow.
The length is used four time so I would not want to remove it. Maybe
rename to CFG80211_FWHW_VERSION_LEN?
Kalle
^ permalink raw reply
* Re: Problems with "cfg80211: fix SME connect" commit
From: Hin-Tak Leung @ 2009-09-24 19:13 UTC (permalink / raw)
To: Johannes Berg; +Cc: Albert Herranz, Holger Schurig, linville, linux-wireless
In-Reply-To: <1253779538.3868.14.camel@johannes.local>
On Thu, Sep 24, 2009 at 9:05 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Mon, 2009-09-21 at 18:11 +0200, Albert Herranz wrote:
>
>> Adding back "cfg80211: fix SME connect" and applying "cfg80211: don't
>> overwrite privacy setting" fixes the connection issue, but with a
>> introduces a small difference vs the previous working version.
>> There is now an extra "deauthenticating by local choice (reason=3)"
>> message in the logs.
>
>> [ 13.969153] b43-phy0 debug: Adding Interface type 2
>> [ 16.679249] wlan1: direct probe to AP 00:12:17:15:e7:79 (try 1)
>
>> * master-20090916 + "cfg80211: don't overwrite privacy setting"
>
>> [ 13.218613] b43-phy0 debug: Adding Interface type 2
>> [ 15.832582] wlan1: deauthenticating by local choice (reason=3)
>> [ 16.131599] wlan1: direct probe to AP 00:12:17:15:e7:79 (try 1)
>
> Very odd. Can you edit the deauthenticating message to show the
> BSSID/MAC address?
>
> johannes
>
This seems to look like/relate to a little problem I have for the last
few days - lately I have authentication failure on first try and have
to click on NM a 2nd time for it to go through; blow away
compat-wireless & revert to as-shipped distro modules gives me the
older/smooth behavior of NM just associating without me
clicking/asking.
v2.6.31-38294-ged3ac87 + 'cfg80211: don't set privacy w/o key' doesn't
improve my situation.
wpa_supplicant log:
--------- distro modules:
Trying to associate with <id> (SSID='ID' freq=2437 MHz)
Associated with <id>
CTRL-EVENT-CONNECTED - Connection to <id> completed (auth) [id=0 id_str=]
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
-------- compat-wireless
Trying to associate with <id> (SSID='ID' freq=2437 MHz)
Authentication with 00:00:00:00:00:00 timed out.
Trying to associate with <id> (SSID='ID' freq=2437 MHz)
Associated with <id>
CTRL-EVENT-CONNECTED - Connection to <id> completed (auth) [id=0 id_str=]
------ dmesg distro modules
wlan2: direct probe to AP <id> try 1
wlan2 direct probe responded
wlan2: authenticate with AP <id>
wlan2: authenticated
wlan2: associate with AP <id>
wlan2: RX AssocResp from <id> (capab=0x431 status=0 aid=1)
wlan2: associated
------ compat-wireless, note the extra deauth at the beginning, and
all those 'try 1''s.
wlan2: deauthenticating by local choice (reason=3)
wlan2: direct probe to AP <id> (try 1)
wlan2 direct probe responded
wlan2: authenticate with AP <id> (try 1)
wlan2: authenticated
wlan2: associate with AP <id> (try 1)
wlan2: RX AssocResp from <id> (capab=0x431 status=0 aid=1)
wlan2: associated
my wpa_supplicant config has two configurations, one (the usual) wep,
and a catch-all generic open network, if that matters.
Most of the instances in wpa log are extra authentication timeouts
with 00:00:00:00:00:00 , but occasionally it is my AP's address.
^ permalink raw reply
* Re: [PATCH 2/2] at76c50x-usb: set firmware and hardware version in wiphy
From: Kalle Valo @ 2009-09-24 19:10 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, Felix Bitterli
In-Reply-To: <43e72e890909241135j21f687a7oc4f929d2134b6310@mail.gmail.com>
On Thu, Sep 24, 2009 at 11:35 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> So ath9k and ath5k keep their own strings for such things, to name the
> MAC/Baseband, and then the radio revision and subrevisions... What I'd
> like to see documented on the kdoc for hw_version is what exactly is
> expected to be put there.
>
> The hw_version and fw_version seem to be helpful in providing more
> information to userspace which you would not typically see -- things
> you would only tend to see on a dmesg output so at least for that
> purpose I think its nice. For example lspci won't really tell you the
> exact hardware type on atheros chipsets, so this seems nice.
Exactly, that's my idea here. And with this the information should be
easy to show in UI.
> Anyway, getting some more clarification on the docs would be nice.
I will definitely add documentation. I meant to send these patches RFC
for the implementation idea, but forgot to do it.
BTW, is there an easy way to get the module name for the interface?
That's also helpful information for the user.
Kalle
^ permalink raw reply
* Re: A problem loading ssb module
From: Luis R. Rodriguez @ 2009-09-24 18:37 UTC (permalink / raw)
To: Hauke Mehrtens, Tim Gardner
Cc: Bryan Wu, Mauro Di Domenico, bcm43xx-dev, linux-wireless
In-Reply-To: <4ABBBB8C.8080401@hauke-m.de>
On Thu, Sep 24, 2009 at 11:33 AM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
> Bryan Wu wrote:
>> Mauro Di Domenico wrote:
>>> Hi,
>>> I'm testing new b43 modules for my 14e4:4315 broadcom card.
>>> I've compiled and installed compat-wireless-2009-09-16 in a debian
>>> machine with kernel version 2.6.30-6.
>>>
>>> During the boot I experience this problem:
>>>
>>> $ dmesg|egrep "b43|ssb"
>>>
>>> [ 2.384463] b43-pci-bridge 0000:06:00.0: PCI INT A -> GSI 17 (level,
>>> low) -> IRQ 17
>>> [ 2.384477] b43-pci-bridge 0000:06:00.0: setting latency timer to 64
>>> [ 2.544344] ssb: Sonics Silicon Backplane found on PCI device
>>> 0000:06:00.0
>>> [ 6.968981] b43: disagrees about version of symbol
>>> ssb_device_is_enabled
>>> [ 6.968986] b43: Unknown symbol ssb_device_is_enabled
>>> [ 6.969280] b43: Unknown symbol ssb_pmu_set_ldo_paref
>>> [ 6.969407] b43: disagrees about version of symbol
>>> ssb_pcicore_dev_irqvecs_enable
>>> [ 6.969410] b43: Unknown symbol ssb_pcicore_dev_irqvecs_enable
>>> .....
>>> ....
>>> ...
>>>
>>
>> I faced the exactly same issue as Mauro did. +1 from me, but currently have
>> no time to take a deeper look.
>>
>> Thanks
> Hi,
>
> I had the same problem with the ssb module and compat-wireless in ubuntu
> 9.04. The problem is that the ssb module is integrated into the
> initramfs image. The version out of the initramfs image is loaded on
> startup and not the version of compat-wireless. Running "sudo
> update-initramfs -u" after installing compat-wireless and restaing the
> system fixes the problem for me. Either Debian/Ubuntu should remove ssb
> form default initramfs image or compat-wireless should update the image
> with the install command. At least the compat-wireless documentation
> needs an update.
>
> Hauke
>
> (adding Luis and linux-wireless list)
Tim, do you guys update the initramfs upon installation of lbm? If a
user does not use lbm and uses compat-wireless I suppose we need to do
something similar.
Luis
^ permalink raw reply
* Re: [PATCH 2/2] at76c50x-usb: set firmware and hardware version in wiphy
From: Luis R. Rodriguez @ 2009-09-24 18:35 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Felix Bitterli
In-Reply-To: <20090924180251.14503.64152.stgit@tikku>
On Thu, Sep 24, 2009 at 11:02 AM, Kalle Valo <kalle.valo@iki.fi> wrote:
> Set firmware and hardware version in wiphy so that user space can access
> it.
>
> Signed-off-by: Kalle Valo <kalle.valo@iki.fi>
> ---
>
> drivers/net/wireless/at76c50x-usb.c | 15 +++++++++++++++
> 1 files changed, 15 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/at76c50x-usb.c b/drivers/net/wireless/at76c50x-usb.c
> index 8e1a55d..b6de657 100644
> --- a/drivers/net/wireless/at76c50x-usb.c
> +++ b/drivers/net/wireless/at76c50x-usb.c
> @@ -2217,6 +2217,8 @@ static struct ieee80211_supported_band at76_supported_band = {
> static int at76_init_new_device(struct at76_priv *priv,
> struct usb_interface *interface)
> {
> + struct wiphy *wiphy;
> + size_t len;
> int ret;
>
> /* set up the endpoint information */
> @@ -2254,6 +2256,7 @@ static int at76_init_new_device(struct at76_priv *priv,
> priv->device_unplugged = 0;
>
> /* mac80211 initialisation */
> + wiphy = priv->hw->wiphy;
> priv->hw->wiphy->max_scan_ssids = 1;
> priv->hw->wiphy->max_scan_ie_len = 0;
> priv->hw->wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION);
> @@ -2265,6 +2268,18 @@ static int at76_init_new_device(struct at76_priv *priv,
> SET_IEEE80211_DEV(priv->hw, &interface->dev);
> SET_IEEE80211_PERM_ADDR(priv->hw, priv->mac_addr);
>
> + len = sizeof(wiphy->fw_version);
> + snprintf(wiphy->fw_version, len, "%d.%d.%d-%d",
> + priv->fw_version.major, priv->fw_version.minor,
> + priv->fw_version.patch, priv->fw_version.build);
> +
> + len = sizeof(wiphy->hw_version);
> + snprintf(wiphy->hw_version, len, "%d", priv->board_type);
So ath9k and ath5k keep their own strings for such things, to name the
MAC/Baseband, and then the radio revision and subrevisions... What I'd
like to see documented on the kdoc for hw_version is what exactly is
expected to be put there.
The hw_version and fw_version seem to be helpful in providing more
information to userspace which you would not typically see -- things
you would only tend to see on a dmesg output so at least for that
purpose I think its nice. For example lspci won't really tell you the
exact hardware type on atheros chipsets, so this seems nice.
Anyway, getting some more clarification on the docs would be nice.
Luis
^ permalink raw reply
* Re: A problem loading ssb module
From: Hauke Mehrtens @ 2009-09-24 18:33 UTC (permalink / raw)
To: Bryan Wu
Cc: Mauro Di Domenico, bcm43xx-dev, Luis R. Rodriguez, linux-wireless
In-Reply-To: <4ABBAB47.8040300@canonical.com>
[-- Attachment #1: Type: text/plain, Size: 1742 bytes --]
Bryan Wu wrote:
> Mauro Di Domenico wrote:
>> Hi,
>> I'm testing new b43 modules for my 14e4:4315 broadcom card.
>> I've compiled and installed compat-wireless-2009-09-16 in a debian
>> machine with kernel version 2.6.30-6.
>>
>> During the boot I experience this problem:
>>
>> $ dmesg|egrep "b43|ssb"
>>
>> [ 2.384463] b43-pci-bridge 0000:06:00.0: PCI INT A -> GSI 17 (level,
>> low) -> IRQ 17
>> [ 2.384477] b43-pci-bridge 0000:06:00.0: setting latency timer to 64
>> [ 2.544344] ssb: Sonics Silicon Backplane found on PCI device
>> 0000:06:00.0
>> [ 6.968981] b43: disagrees about version of symbol
>> ssb_device_is_enabled
>> [ 6.968986] b43: Unknown symbol ssb_device_is_enabled
>> [ 6.969280] b43: Unknown symbol ssb_pmu_set_ldo_paref
>> [ 6.969407] b43: disagrees about version of symbol
>> ssb_pcicore_dev_irqvecs_enable
>> [ 6.969410] b43: Unknown symbol ssb_pcicore_dev_irqvecs_enable
>> .....
>> ....
>> ...
>>
>
> I faced the exactly same issue as Mauro did. +1 from me, but currently have
> no time to take a deeper look.
>
> Thanks
Hi,
I had the same problem with the ssb module and compat-wireless in ubuntu
9.04. The problem is that the ssb module is integrated into the
initramfs image. The version out of the initramfs image is loaded on
startup and not the version of compat-wireless. Running "sudo
update-initramfs -u" after installing compat-wireless and restaing the
system fixes the problem for me. Either Debian/Ubuntu should remove ssb
form default initramfs image or compat-wireless should update the image
with the install command. At least the compat-wireless documentation
needs an update.
Hauke
(adding Luis and linux-wireless list)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 898 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] cfg80211: add firmware and hardware version to wiphy
From: Luis R. Rodriguez @ 2009-09-24 18:32 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <20090924180242.14503.11148.stgit@tikku>
On Thu, Sep 24, 2009 at 11:02 AM, Kalle Valo <kalle.valo@iki.fi> wrote:
> From: Kalle Valo <kalle.valo@nokia.com>
>
> It's useful to provide firmware and hardware version to user space and have a
> generic interface to retrieve them. Users can provide the version information
> in bug reports etc.
>
> Add fields for firmware and hardware version to struct wiphy and return
> them to user space in NL80211_CMD_GET_WIPHY reply.
Wow that was quick :)
> Signed-off-by: Kalle Valo <kalle.valo@nokia.com>
> ---
>
> include/linux/nl80211.h | 3 +++
> include/net/cfg80211.h | 5 +++++
> net/wireless/nl80211.c | 11 +++++++++++
> 3 files changed, 19 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
> index a8d71ed..6d6651f 100644
> --- a/include/linux/nl80211.h
> +++ b/include/linux/nl80211.h
> @@ -714,6 +714,9 @@ enum nl80211_attrs {
>
> NL80211_ATTR_PID,
>
> + NL80211_ATTR_FW_VERSION,
> + NL80211_ATTR_HW_VERSION,
> +
Some kdoc on this would be nice.
> /* add attributes here, update the policy in nl80211.c */
>
> __NL80211_ATTR_AFTER_LAST,
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index 3d874c6..de3da19 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -1070,6 +1070,8 @@ struct cfg80211_ops {
> * and registration/helper functions
> */
>
> +#define CFG80211_VERSION_LEN 32
Probably best to just remove this or at least make this not just
CFG80211_VERSION_LEN, seems like this is related to cfg80211's version
somehow.
Luis
^ permalink raw reply
* Re: 2.6.31-git wireless broken
From: Johannes Berg @ 2009-09-24 18:23 UTC (permalink / raw)
To: Hugh Dickins; +Cc: John W. Linville, Rafael J. Wysocki, linux-wireless
In-Reply-To: <Pine.LNX.4.64.0909241859020.25022@sister.anvils>
[-- Attachment #1: Type: text/plain, Size: 1478 bytes --]
On Thu, 2009-09-24 at 19:14 +0100, Hugh Dickins wrote:
> I've been working under the belief that it's WPA encrypted.
>
> > If it's open, can you try this patch?
>
> But I could try the patch, in case I've been fooled.
>
> > http://johannes.sipsolutions.net/patches/kernel/all/2009-09-24-17%3a32/010-cfg80211-fix-wpas-open.patch
>
> However, all the trees I'm working with (Linus latest, or the bisect
> result, or a week old mmotm) have cfg80211_mgd_wext_connect saying:
>
> if (!netif_running(wdev->netdev))
> return 0;
>
> wdev->wext.connect.ie = wdev->wext.ie;
> wdev->wext.connect.ie_len = wdev->wext.ie_len;
> wdev->wext.connect.privacy = wdev->wext.default_key != -1;
>
> if (wdev->wext.keys) {
> wdev->wext.keys->def = wdev->wext.default_key;
> wdev->wext.keys->defmgmt = wdev->wext.default_mgmt_key;
> }
>
> if (!wdev->wext.connect.ssid_len)
> return 0;
>
> which is not consistent with the fix your patch is making.
Ah. That patch isn't in yet I guess. I wonder if that could still be an
issue though. Maybe you can try that patch along with this one:
http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commitdiff_plain;h=55a00b83339f25d2979b85ab6e2151390327db80;hp=cfa53f1e753ed709f0a483fa8bd16bc7d08d402d
Anyhow, I'm grasping at straws -- can you tell me more about the failure
mode, and possibly enable CONFIG_MAC80211_DEBUG_MENU and
CONFIG_MAC80211_VERBOSE_DEBUG?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: 2.6.31-git wireless broken
From: Hugh Dickins @ 2009-09-24 18:14 UTC (permalink / raw)
To: Johannes Berg; +Cc: John W. Linville, Rafael J. Wysocki, linux-wireless
In-Reply-To: <1253813740.3868.324.camel@johannes.local>
Many thanks for your rapid response.
On Thu, 24 Sep 2009, Johannes Berg wrote:
> On Thu, 2009-09-24 at 18:18 +0100, Hugh Dickins wrote:
> >
> > I expect you'll need a lot more info from me: please do ask
> > (but bear in mind that I'm wireless and network ignorant).
>
> Thanks. I'm not sure why you'd get the warning there every few seconds,
> but I suppose we don't really care all that much.
>
> I think you're probably running afoul of a bugfix that I did while at
> the wireless summit, and then the fix to it made it in, but not yet the
> fix to the fix :(
>
> Are you using an encrypted network, or an open one?
I've been working under the belief that it's WPA encrypted.
> If it's open, can you try this patch?
But I could try the patch, in case I've been fooled.
> http://johannes.sipsolutions.net/patches/kernel/all/2009-09-24-17%3a32/010-cfg80211-fix-wpas-open.patch
However, all the trees I'm working with (Linus latest, or the bisect
result, or a week old mmotm) have cfg80211_mgd_wext_connect saying:
if (!netif_running(wdev->netdev))
return 0;
wdev->wext.connect.ie = wdev->wext.ie;
wdev->wext.connect.ie_len = wdev->wext.ie_len;
wdev->wext.connect.privacy = wdev->wext.default_key != -1;
if (wdev->wext.keys) {
wdev->wext.keys->def = wdev->wext.default_key;
wdev->wext.keys->defmgmt = wdev->wext.default_mgmt_key;
}
if (!wdev->wext.connect.ssid_len)
return 0;
which is not consistent with the fix your patch is making.
But I do believe I'm encrypted anyway.
Hugh
^ permalink raw reply
* [PATCH 2/2] iw: print firmware and hardware version
From: Kalle Valo @ 2009-09-24 18:09 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20090924180048.14503.9579.stgit@tikku>
struct wiphy now contains firmware and hardware version, print that
information to the user.
---
info.c | 15 +++++++++++++++
nl80211.h | 3 +++
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/info.c b/info.c
index 7bca69d..ae3ed54 100644
--- a/info.c
+++ b/info.c
@@ -66,6 +66,7 @@ static int print_phy_handler(struct nl_msg *msg, void *arg)
struct nlattr *nl_freq;
struct nlattr *nl_rate;
struct nlattr *nl_mode;
+ const char *str;
int bandidx = 1;
int rem_band, rem_freq, rem_rate, rem_mode;
int open;
@@ -263,6 +264,20 @@ static int print_phy_handler(struct nl_msg *msg, void *arg)
printf("\tRTS threshold: %d\n", rts);
}
+ if (tb_msg[NL80211_ATTR_FW_VERSION]) {
+ str = nla_get_string(tb_msg[NL80211_ATTR_FW_VERSION]);
+ if (strlen(str) == 0)
+ str = "<unknown>";
+ printf("\tFirmware version: %s\n", str);
+ }
+
+ if (tb_msg[NL80211_ATTR_HW_VERSION]) {
+ str = nla_get_string(tb_msg[NL80211_ATTR_HW_VERSION]);
+ if (strlen(str) == 0)
+ str = "<unknown>";
+ printf("\tHardware version: %s\n", str);
+ }
+
if (!tb_msg[NL80211_ATTR_SUPPORTED_IFTYPES])
return NL_SKIP;
diff --git a/nl80211.h b/nl80211.h
index a8d71ed..6d6651f 100644
--- a/nl80211.h
+++ b/nl80211.h
@@ -714,6 +714,9 @@ enum nl80211_attrs {
NL80211_ATTR_PID,
+ NL80211_ATTR_FW_VERSION,
+ NL80211_ATTR_HW_VERSION,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
^ permalink raw reply related
* [PATCH 1/2] iw: update nl80211.h from wireless-testing
From: Kalle Valo @ 2009-09-24 18:09 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20090924180048.14503.9579.stgit@tikku>
---
nl80211.h | 26 +++++++++++++++++++++-----
1 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/nl80211.h b/nl80211.h
index 962e223..a8d71ed 100644
--- a/nl80211.h
+++ b/nl80211.h
@@ -262,6 +262,9 @@
* reasons, for this the %NL80211_ATTR_DISCONNECTED_BY_AP and
* %NL80211_ATTR_REASON_CODE attributes are used.
*
+ * @NL80211_CMD_SET_WIPHY_NETNS: Set a wiphy's netns. Note that all devices
+ * associated with this wiphy must be down and will follow.
+ *
* @NL80211_CMD_MAX: highest used command number
* @__NL80211_CMD_AFTER_LAST: internal use
*/
@@ -336,6 +339,8 @@ enum nl80211_commands {
NL80211_CMD_ROAM,
NL80211_CMD_DISCONNECT,
+ NL80211_CMD_SET_WIPHY_NETNS,
+
/* add new commands above here */
/* used to define NL80211_CMD_MAX below */
@@ -475,10 +480,6 @@ enum nl80211_commands {
* @NL80211_ATTR_SCAN_FREQUENCIES: nested attribute with frequencies (in MHz)
* @NL80211_ATTR_SCAN_SSIDS: nested attribute with SSIDs, leave out for passive
* scanning and include a zero-length SSID (wildcard) for wildcard scan
- * @NL80211_ATTR_SCAN_GENERATION: the scan generation increases whenever the
- * scan result list changes (BSS expired or added) so that applications
- * can verify that they got a single, consistent snapshot (when all dump
- * messages carried the same generation number)
* @NL80211_ATTR_BSS: scan result BSS
*
* @NL80211_ATTR_REG_INITIATOR: indicates who requested the regulatory domain
@@ -573,6 +574,16 @@ enum nl80211_commands {
* and join_ibss(), key information is in a nested attribute each
* with %NL80211_KEY_* sub-attributes
*
+ * @NL80211_ATTR_PID: Process ID of a network namespace.
+ *
+ * @NL80211_ATTR_GENERATION: Used to indicate consistent snapshots for
+ * dumps. This number increases whenever the object list being
+ * dumped changes, and as such userspace can verify that it has
+ * obtained a complete and consistent snapshot by verifying that
+ * all dump messages contain the same generation number. If it
+ * changed then the list changed and the dump should be repeated
+ * completely from scratch.
+ *
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
*/
@@ -644,7 +655,7 @@ enum nl80211_attrs {
NL80211_ATTR_SCAN_FREQUENCIES,
NL80211_ATTR_SCAN_SSIDS,
- NL80211_ATTR_SCAN_GENERATION,
+ NL80211_ATTR_GENERATION, /* replaces old SCAN_GENERATION */
NL80211_ATTR_BSS,
NL80211_ATTR_REG_INITIATOR,
@@ -701,12 +712,17 @@ enum nl80211_attrs {
NL80211_ATTR_KEY,
NL80211_ATTR_KEYS,
+ NL80211_ATTR_PID,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
NL80211_ATTR_MAX = __NL80211_ATTR_AFTER_LAST - 1
};
+/* source-level API compatibility */
+#define NL80211_ATTR_SCAN_GENERATION NL80211_ATTR_GENERATION
+
/*
* Allow user space programs to use #ifdef on new attributes by defining them
* here
^ permalink raw reply related
* [PATCH 2/2] at76c50x-usb: set firmware and hardware version in wiphy
From: Kalle Valo @ 2009-09-24 18:02 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20090924180048.14503.9579.stgit@tikku>
Set firmware and hardware version in wiphy so that user space can access
it.
Signed-off-by: Kalle Valo <kalle.valo@iki.fi>
---
drivers/net/wireless/at76c50x-usb.c | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/at76c50x-usb.c b/drivers/net/wireless/at76c50x-usb.c
index 8e1a55d..b6de657 100644
--- a/drivers/net/wireless/at76c50x-usb.c
+++ b/drivers/net/wireless/at76c50x-usb.c
@@ -2217,6 +2217,8 @@ static struct ieee80211_supported_band at76_supported_band = {
static int at76_init_new_device(struct at76_priv *priv,
struct usb_interface *interface)
{
+ struct wiphy *wiphy;
+ size_t len;
int ret;
/* set up the endpoint information */
@@ -2254,6 +2256,7 @@ static int at76_init_new_device(struct at76_priv *priv,
priv->device_unplugged = 0;
/* mac80211 initialisation */
+ wiphy = priv->hw->wiphy;
priv->hw->wiphy->max_scan_ssids = 1;
priv->hw->wiphy->max_scan_ie_len = 0;
priv->hw->wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION);
@@ -2265,6 +2268,18 @@ static int at76_init_new_device(struct at76_priv *priv,
SET_IEEE80211_DEV(priv->hw, &interface->dev);
SET_IEEE80211_PERM_ADDR(priv->hw, priv->mac_addr);
+ len = sizeof(wiphy->fw_version);
+ snprintf(wiphy->fw_version, len, "%d.%d.%d-%d",
+ priv->fw_version.major, priv->fw_version.minor,
+ priv->fw_version.patch, priv->fw_version.build);
+
+ len = sizeof(wiphy->hw_version);
+ snprintf(wiphy->hw_version, len, "%d", priv->board_type);
+
+ /* null terminate the strings in case they were truncated */
+ wiphy->fw_version[len - 1] = '\0';
+ wiphy->hw_version[len - 1] = '\0';
+
ret = ieee80211_register_hw(priv->hw);
if (ret) {
printk(KERN_ERR "cannot register mac80211 hw (status %d)!\n",
^ permalink raw reply related
* [PATCH 0/2] cfg80211: firmware and hardware version
From: Kalle Valo @ 2009-09-24 18:02 UTC (permalink / raw)
To: linux-wireless
Here's my suggestion how to provide firmware and hardware version to
user space. First I was thinking adding a new nl80211 command and
it looked so ugly that I decided include the versions in struct wiphy
instead.
Please comment.
---
Kalle Valo (2):
at76c50x-usb: set firmware and hardware version in wiphy
cfg80211: add firmware and hardware version to wiphy
drivers/net/wireless/at76c50x-usb.c | 15 +++++++++++++++
include/linux/nl80211.h | 3 +++
include/net/cfg80211.h | 5 +++++
net/wireless/nl80211.c | 11 +++++++++++
4 files changed, 34 insertions(+), 0 deletions(-)
^ permalink raw reply
* [PATCH 1/2] cfg80211: add firmware and hardware version to wiphy
From: Kalle Valo @ 2009-09-24 18:02 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20090924180048.14503.9579.stgit@tikku>
From: Kalle Valo <kalle.valo@nokia.com>
It's useful to provide firmware and hardware version to user space and have a
generic interface to retrieve them. Users can provide the version information
in bug reports etc.
Add fields for firmware and hardware version to struct wiphy and return
them to user space in NL80211_CMD_GET_WIPHY reply.
Signed-off-by: Kalle Valo <kalle.valo@nokia.com>
---
include/linux/nl80211.h | 3 +++
include/net/cfg80211.h | 5 +++++
net/wireless/nl80211.c | 11 +++++++++++
3 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
index a8d71ed..6d6651f 100644
--- a/include/linux/nl80211.h
+++ b/include/linux/nl80211.h
@@ -714,6 +714,9 @@ enum nl80211_attrs {
NL80211_ATTR_PID,
+ NL80211_ATTR_FW_VERSION,
+ NL80211_ATTR_HW_VERSION,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 3d874c6..de3da19 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1070,6 +1070,8 @@ struct cfg80211_ops {
* and registration/helper functions
*/
+#define CFG80211_VERSION_LEN 32
+
/**
* struct wiphy - wireless hardware description
* @idx: the wiphy index assigned to this item
@@ -1142,6 +1144,9 @@ struct wiphy {
u32 frag_threshold;
u32 rts_threshold;
+ char fw_version[CFG80211_VERSION_LEN];
+ char hw_version[CFG80211_VERSION_LEN];
+
/* If multiple wiphys are registered and you're handed e.g.
* a regular netdev with assigned ieee80211_ptr, you won't
* know whether it points to a wiphy your driver has registered
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index eddab09..9e2214e 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -138,6 +138,14 @@ static struct nla_policy nl80211_policy[NL80211_ATTR_MAX+1] __read_mostly = {
[NL80211_ATTR_CIPHER_SUITE_GROUP] = { .type = NLA_U32 },
[NL80211_ATTR_WPA_VERSIONS] = { .type = NLA_U32 },
[NL80211_ATTR_PID] = { .type = NLA_U32 },
+ [NL80211_ATTR_FW_VERSION] = {
+ .type = NLA_NUL_STRING,
+ .len = CFG80211_VERSION_LEN,
+ },
+ [NL80211_ATTR_HW_VERSION] = {
+ .type = NLA_NUL_STRING,
+ .len = CFG80211_VERSION_LEN,
+ },
};
/* policy for the attributes */
@@ -420,6 +428,9 @@ static int nl80211_send_wiphy(struct sk_buff *msg, u32 pid, u32 seq, int flags,
NLA_PUT_U32(msg, NL80211_ATTR_WIPHY_RTS_THRESHOLD,
dev->wiphy.rts_threshold);
+ NLA_PUT_STRING(msg, NL80211_ATTR_FW_VERSION, dev->wiphy.fw_version);
+ NLA_PUT_STRING(msg, NL80211_ATTR_HW_VERSION, dev->wiphy.hw_version);
+
NLA_PUT_U8(msg, NL80211_ATTR_MAX_NUM_SCAN_SSIDS,
dev->wiphy.max_scan_ssids);
NLA_PUT_U16(msg, NL80211_ATTR_MAX_SCAN_IE_LEN,
^ permalink raw reply related
* Re: 2.6.31-git wireless broken
From: Johannes Berg @ 2009-09-24 17:35 UTC (permalink / raw)
To: Hugh Dickins; +Cc: John W. Linville, Rafael J. Wysocki, linux-wireless
In-Reply-To: <Pine.LNX.4.64.0909241737390.20846@sister.anvils>
[-- Attachment #1: Type: text/plain, Size: 1695 bytes --]
On Thu, 2009-09-24 at 18:18 +0100, Hugh Dickins wrote:
> I've noticed for a while that wireless is broken in linux-next, on both
> the machines I use it on (a Fujitsu Siemens laptop using iwl3945 and an
> Acer Aspire One using ath5k: both running openSUSE 11.1, with WPA):
> I hoped to find it fixed later, but no, Linus's git is broken now.
>
> Only found time to bisect it a couple of days ago (on the Aspire One:
> guess the other would show the same, but that's no more than a guess).
> It arrived at the commit below as the culprit, which from your own
> words doesn't seem like a very hopeful place to land :-(
>
> That commit does give me a "WARNING: at net/mac80211/mlme.c:1904",
> followed by "WARNING: at net/mac80211/mlme.c:2308" every few seconds;
> and those do get fixed later on (don't appear with latest git).
> But I think there's another problem that comes in later, because
> at this commit iwconfig does show my ESSID, whereas with later
> git it just says "ESSID:off/any" (I have not bisected when that
> change comes in).
>
> I expect you'll need a lot more info from me: please do ask
> (but bear in mind that I'm wireless and network ignorant).
Thanks. I'm not sure why you'd get the warning there every few seconds,
but I suppose we don't really care all that much.
I think you're probably running afoul of a bugfix that I did while at
the wireless summit, and then the fix to it made it in, but not yet the
fix to the fix :(
Are you using an encrypted network, or an open one? If it's open, can
you try this patch?
http://johannes.sipsolutions.net/patches/kernel/all/2009-09-24-17%3a32/010-cfg80211-fix-wpas-open.patch
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: rfkill hard state after booting
From: Johannes Berg @ 2009-09-24 17:29 UTC (permalink / raw)
To: Alan Jenkins
Cc: Norbert Preining, linux-wireless, Mattia Dongili,
Almer S. Tigelaar, Matthias Welwarsky
In-Reply-To: <4ABB8C5E.6070402@tuffmail.co.uk>
[-- Attachment #1: Type: text/plain, Size: 580 bytes --]
On Thu, 2009-09-24 at 16:12 +0100, Alan Jenkins wrote:
> > Although maybe it should just call sony_nc_rfkill_update() after
> > registering all of them?
> That means the initial "add" uevents etc. will contain wrong values (and
> then be updated immediately after). Do we care about that? It's
> unlikely to matter in practice for platform devices which only get
> loaded at boot-time, but perhaps it would set a bad example.
Ah, good point. I was just a little concerned about the logic
difference, but I don't really understand the _update() logic.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox