Hi,
I was just giving the prism54pci code a whirl, with my NetComm NP5430
Cardbus card, and it BUGged the kernel during driver load (or
immediately after driver load failed, I guess) as follows:
Mar 17 02:34:23 su kernel: pccard: CardBus card inserted into slot 0
Mar 17 02:34:23 su kernel: PCI: Enabling device 0001:11:00.0 (0000 -> 0002)
Mar 17 02:34:23 su kernel: p54: LM86 firmware
Mar 17 02:34:25 su kernel: 0001:11:00.0 (prism54pci): Cannot read eeprom!
Mar 17 02:34:25 su kernel: prism54pci: probe of 0001:11:00.0 failed with error -22
Mar 17 02:34:25 su kernel: pci 0001:11:00.0: Error adding device, continuing
Mar 17 02:34:25 su kernel: ------------[ cut here ]------------
Mar 17 02:34:25 su kernel: kernel BUG at drivers/pci/bus.c:127!
Mar 17 02:34:25 su kernel: Oops: Exception in kernel mode, sig: 5 [#1]
Mar 17 02:34:25 su kernel: PREEMPT
Mar 17 02:34:25 su kernel: Modules linked in: prism54pci prism54common cdc_subset cdc_ether usbnet binfmt_misc rfcomm ipv6 af_packet fuse hci_usb l2cap bluetooth cpufreq_stats cpufreq_userspace cpufreq_powersave cpufreq_conservative i2c_dev snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_seq_device radeon drm therm_adt746x sbp2 scsi_mod snd_aoa_codec_tas snd_aoa_fabric_layout snd_aoa snd_aoa_i2sbus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd pcmcia soundcore firmware_class ssb snd_aoa_soundbus mac80211 yenta_socket rsrc_nonstatic pcmcia_core evdev uninorth_agp agpgart cfg80211 ext3 jbd mbcache sungem sungem_phy ohci1394 ieee1394 ide_cd cdrom
Mar 17 02:34:25 su kernel: NIP: C0107A2C LR: C01079E8 CTR: C002636C
Mar 17 02:34:25 su kernel: REGS: c2601e80 TRAP: 0700 Tainted: GF (2.6.20)
Mar 17 02:34:25 su kernel: MSR: 00029032 <EE,ME,IR,DR> CR: 28000024 XER: 00000000
Mar 17 02:34:25 su kernel: TASK = c241b210[1462] 'pccardd' THREAD: c2600000
Mar 17 02:34:25 su kernel: GPR00: 00000001 C2601F30 C241B210 C257100C 00000001 00000000 00000000 00000000
Mar 17 02:34:25 su kernel: GPR08: 00000000 D9EA8008 00004336 C2600000 00000000 00000000 00000000 00000000
Mar 17 02:34:25 su kernel: GPR16: 00000000 00000000 00000000 00000000 00000000 41400000 016AE808 016AEA24
Mar 17 02:34:25 su kernel: GPR24: 00000000 00327000 DFFF5900 C28EBCE8 00000002 C2571014 C2571000 D9EA8000
Mar 17 02:34:25 su kernel: NIP [C0107A2C] pci_bus_add_devices+0x94/0x164
Mar 17 02:34:25 su kernel: LR [C01079E8] pci_bus_add_devices+0x50/0x164
Mar 17 02:34:25 su kernel: Call Trace:
Mar 17 02:34:25 su kernel: [C2601F30] [C01079E8] pci_bus_add_devices+0x50/0x164 (unreliable)
Mar 17 02:34:25 su kernel: [C2601F50] [E2261684] cb_alloc+0xe0/0x100 [pcmcia_core]
Mar 17 02:34:25 su kernel: [C2601F70] [E225DA0C] socket_insert+0x100/0x140 [pcmcia_core]
Mar 17 02:34:25 su kernel: [C2601F80] [E225E028] pccardd+0x1a8/0x258 [pcmcia_core]
Mar 17 02:34:25 su kernel: [C2601FC0] [C004261C] kthread+0xc4/0x100
Mar 17 02:34:25 su kernel: [C2601FF0] [C00121C4] kernel_thread+0x44/0x60
Mar 17 02:34:25 su kernel: Instruction dump:
Mar 17 02:34:25 su kernel: 7c00022c 3bbf0008 381e0014 7f9d0000 7fe3fb78 409effa4 813e0014 480000b0
Mar 17 02:34:25 su kernel: 801f0000 7c00fa78 7c000034 5400d97e <0f000000> 817f0014 2f8b0000 419e008c
When I then pulled the card out, the machine hardlocked. >_< (Hooray for
sync!)
It's a Debian-sourced 2.6.20 kernel with the Intel mac80211 4.0.4
patchset applied as well as a patch to revert the bad get_order changes.
The (built-in) bcm43xx-mac80211 driver works, but when I try to load a
CardBus Atheros card I've got lying around with dadwifi-openhal, it
fails with some sort of hardware error. (ie. it _might_ be a dodgey
Cardbus port, although both cardbus cards used to work in this machine,
using prism54 hardmac and the dadwifi with atheros hal driver
respectively)
(Albeit the hardmach driver never managed to WPA, and as of 2.6.20 still
doesn't, haven't tried the version in wireless-dev yet)
The card reports itself in lspci as:
0001:11:00.0 Network controller: Intersil Corporation ISL3890 [Prism GT/Prism Duette]/ISL3886 [Prism Javelin/Prism Xbow] (rev 01)
0001:11:00.0 0280: 1260:3890 (rev 01)
The machine is a PowerBook G4 15", PowerPC.
The drivers are from wireless-dev 4533da881f2d8c3e0dbb5b3dbc7a919e12438a8a
built with the following shell script:
#! /bin/sh
KERN=2.6.20
KPATH=/usr/src/linux-headers-$KERN/
cd build/ssb
make -C $KPATH CFLAGS_MODULE="-DMODULE -I"$PWD"/../include -DCONFIG_SSB=m -DCONFIG_SSB_PCIHOST=y -DCONFIG_SSB_DRIVER_PCICORE=y" M="$PWD" CONFIG_SSB=m CONFIG_SSB_PCIHOST=y CONFIG_SSB_DRIVER_PCICORE=y $*
cd ../..
cd build/bcm43xx
make -C $KPATH CFLAGS_MODULE="-DMODULE -I"$PWD"/../include -DCONFIG_SSB=m -DCONFIG_SSB_PCIHOST=y -DCONFIG_SSB_DRIVER_PCICORE=y -DCONFIG_BCM43XX_MAC80211=m -DCONFIG_BCM43XX_MAC80211_PCI=y -DCONFIG_BCM43XX_MAC80211_DEBUG=y -DCONFIG_BCM43XX_MAC80211_DMA=y -DCONFIG_BCM43XX_MAC80211_PIO=y" M="$PWD" CONFIG_SSB=m CONFIG_SSB_PCIHOST=y CONFIG_SSB_DRIVER_PCICORE=y CONFIG_BCM43XX_MAC80211=m CONFIG_BCM43XX_MAC80211_PCI=y CONFIG_BCM43XX_MAC80211_DEBUG=y CONFIG_BCM43XX_MAC80211_DMA=y CONFIG_BCM43XX_MAC80211_PIO=y $*
cd ../..
cd build/p54
make -C $KPATH CFLAGS_MODULE="-DMODULE -DCONFIG_P54_COMMON=m -DCONFIG_P54_PCI=m" M="$PWD" CONFIG_P54_COMMON=m CONFIG_P54_PCI=m $*
The prism54 firmwares in /lib/firmware are:
09f9da7ea757173c9de1a0322a1f9782 /lib/firmware/isl3886
tbble@su:~$ hd /lib/firmware/isl3886 |head
00000000 00 00 a0 e1 80 f3 9f e5 00 00 00 00 00 00 00 00 |................|
00000010 00 00 00 00 01 00 00 80 01 00 00 00 4c 4d 38 36 |............LM86|
00000020 02 00 00 80 06 00 00 00 32 2e 37 2e 30 2e 30 00 |........2.7.0.0.|
8bd4310971772a486b9784c77f8a6df9 /lib/firmware/isl3890
tbble@su:~$ hd /lib/firmware/isl3890 |head
00000000 36 00 00 ea 35 00 00 ea 34 00 00 ea 33 00 00 ea |6...5...4...3...|
00000010 32 00 00 ea 01 00 00 80 01 00 00 00 4c 43 4c 31 |2...........LCL1|
00000020 02 00 00 80 06 00 00 00 31 2e 30 2e 34 2e 33 00 |........1.0.4.3.|
The code where it BUGS:
/**
* add a single device
* @dev: device to add
*
* This adds a single pci device to the global
* device list and adds sysfs and procfs entries
*/
int __devinit pci_bus_add_device(struct pci_dev *dev)
{
int retval;
retval = device_add(&dev->dev);
if (retval)
return retval;
down_write(&pci_bus_sem);
list_add_tail(&dev->global_list, &pci_devices);
up_write(&pci_bus_sem);
pci_proc_attach_device(dev);
pci_create_sysfs_dev_files(dev);
return 0;
}
/**
* pci_bus_add_devices - insert newly discovered PCI devices
* @bus: bus to check for new devices
*
* Add newly discovered PCI devices (which are on the bus->devices
* list) to the global PCI device list, add the sysfs and procfs
* entries. Where a bridge is found, add the discovered bus to
* the parents list of child buses, and recurse (breadth-first
* to be compatible with 2.4)
*
* Call hotplug for each new devices.
*/
void __devinit pci_bus_add_devices(struct pci_bus *bus)
{
struct pci_dev *dev;
int retval;
list_for_each_entry(dev, &bus->devices, bus_list) {
/*
* Skip already-present devices (which are on the
* global device list.)
*/
if (!list_empty(&dev->global_list))
continue;
retval = pci_bus_add_device(dev);
if (retval)
dev_err(&dev->dev, "Error adding device, continuing\n");
}
list_for_each_entry(dev, &bus->devices, bus_list) {
127: BUG_ON(list_empty(&dev->global_list));
/*
* If there is an unattached subordinate bus, attach
* it and then scan for unattached PCI devices.
*/
if (dev->subordinate) {
if (list_empty(&dev->subordinate->node)) {
down_write(&pci_bus_sem);
list_add_tail(&dev->subordinate->node,
&dev->bus->children);
up_write(&pci_bus_sem);
}
pci_bus_add_devices(dev->subordinate);
retval = sysfs_create_link(&dev->subordinate->class_dev.kobj,
&dev->dev.kobj, "bridge");
if (retval)
dev_err(&dev->dev, "Error creating sysfs "
"bridge symlink, continuing...\n");
}
}
}
In this case, I get the 'Error adding device', which means
list_add_tail(&dev->global_list, &pci_devices) wasn't called in
pci_bus_add_device. This implies that the failure path for
device_add (in this case, AttachError: calling bus_attach_device in
drivers/base/core.c, which ends up collecting the -EINVAL from the
probe) should be removing the device from bus->devices (I think...)
but I guess it's not.
So maybe the BUG isn't a problem with the p54 driver, but I'd appreciate
help with making it find the eeprom so it doesn't happen...
--
-----------------------------------------------------------
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[email protected]
Of course Pacman didn't influence us as kids. If it did,
we'd be running around in darkened rooms, popping pills and
listening to repetitive music.
-- Kristian Wilson, Nintendo, Inc, 1989
License: http://creativecommons.org/licenses/by/2.1/au/
-----------------------------------------------------------
On Sat, Mar 17, 2007 at 05:52:43PM +1100, Paul TBBle Hampson wrote:
> Mar 17 17:47:00 su kernel: wlan1: duplicate address detected!
OK, I've confirmed that I still get the above with both dadwifi and
bcm43xx-mac80211
A tcpdump indicates that my laptop sees its own neighbour-announce come
back, and assumes that's a different machine sending it, failing the
duplicate address detection.
A tcdump against the ethernet device (or bcm43xx from 2.6.20) does not
see the neighbour-announce come back, and so passes the duplicate
address detection, and gets an autoconfig IPv6 address.
I thought it might be the lack of IFF_BROADCAST which was fixed a while
ago, but it's still there.
kernel 2.6.20 from debian, patched with get_order() fix from 2.6.20.2
modular mac80211 stack from intel's 4.0.4 tarball, patched into kernel
bcm43xx-mac80211 from wireless-dev
dadwifi from madwifi.org subversion repository
--
-----------------------------------------------------------
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[email protected]
Of course Pacman didn't influence us as kids. If it did,
we'd be running around in darkened rooms, popping pills and
listening to repetitive music.
-- Kristian Wilson, Nintendo, Inc, 1989
License: http://creativecommons.org/licenses/by/2.1/au/
-----------------------------------------------------------
On Saturday 17 March 2007 00:50, Pavel Roskin wrote:
> Oh, and I'm amazed that somebody is using dadwifi-openhal verify the
> hardware! It's in a pretty poor shape right now. It prints some
> warnings because it starts with channel 0. The interface can be brought
> up if you set a valid channel, and I think it might scan.
>
Really? mac80211 should set the channel immediately after bringing the
interface. If no channel is configured, it defaults to the first channel in
the first mode that is registered.
-Michael Wu
On Friday 16 March 2007 23:46, Paul TBBle Hampson wrote:
> The (built-in) bcm43xx-mac80211 driver works, but when I try to load a
> CardBus Atheros card I've got lying around with dadwifi-openhal, it
> fails with some sort of hardware error. (ie. it _might_ be a dodgey
> Cardbus port, although both cardbus cards used to work in this machine,
> using prism54 hardmac and the dadwifi with atheros hal driver
> respectively)
>
Can you rule out the port first? Load the fullmac driver first, bring it up &
down, unload it, and then try p54.
> (Albeit the hardmach driver never managed to WPA, and as of 2.6.20 still
> doesn't, haven't tried the version in wireless-dev yet)
>
Hardmac version in wireless-dev is the same thing. wireless-dev is just for
mac80211 and cfg80211 code.
> So maybe the BUG isn't a problem with the p54 driver, but I'd appreciate
> help with making it find the eeprom so it doesn't happen...
I just found a leak in a probe error path. It might somehow cause the problem
in the pci code. I've attached a patch to fix it.
Thanks,
-Michael Wu
On Saturday 17 March 2007 02:15, Paul TBBle Hampson wrote:
> ] rmmod prism54
> Mar 17 16:43:26 su kernel: prism54-0: removing device
> Mar 17 16:43:26 su kernel: Unloaded prism54 driver
>
> Then, with the p54 code, patched with the patch you attached.
>
> ] modprobe prism54pci
> Mar 17 16:48:56 su kernel: p54: LM86 firmware
> Mar 17 16:48:58 su kernel: 0001:11:00.0 (prism54pci): Cannot read eeprom!
> Mar 17 16:48:58 su kernel: prism54pci: probe of 0001:11:00.0 failed with
> error -22
>
> Hmm, I guess the patch fixed the BUG_ON. ^_^
>
Ok good, thanks for testing!
> Still fails to read an eeprom from my card though. I'm wondering if the
> crapspew from the prism54 driver implies card or socket badness?
>
These devices do go bad, so a broken card isn't out of the question. However..
> However, the hardmac driver is able to get a MAC address (with an OID
> query, according to the code) and the MAC address is correct:
> 00:60:64:03:41:81
>
My broken card never got that far.
> Is it worth dumping the purported eeprom to see if it's actually a valid
> eeprom in a format unexpected by the code? (The card is very old now...)
>
Actually, the code doesn't check (but it does report) if parsing fails so a
corrupted eeprom can't be the reason for probe failure. I'll get that fixed
next week..
So anyway, your card isn't even returning the eeprom data. Only thing I can
think of is fiddling with the mdelay in that (p54p_read_eeprom) function
(there's only one). Try making it bigger. That mdelay solved problems with
eeprom reading on module reload but it's very close to the minimum delay
needed there.
-Michael Wu
On Sat, Mar 17, 2007 at 12:37:10AM -0400, Michael Wu wrote:
> On Friday 16 March 2007 23:46, Paul TBBle Hampson wrote:
>> The (built-in) bcm43xx-mac80211 driver works, but when I try to load a
>> CardBus Atheros card I've got lying around with dadwifi-openhal, it
>> fails with some sort of hardware error. (ie. it _might_ be a dodgey
>> Cardbus port, although both cardbus cards used to work in this machine,
>> using prism54 hardmac and the dadwifi with atheros hal driver
>> respectively)
> Can you rule out the port first? Load the fullmac driver first, bring it up &
> down, unload it, and then try p54.
OK, with the current prism54 as it appears in wireless-dev:
Mar 17 16:32:41 su kernel: pccard: CardBus card inserted into slot 0
] modprobe prism54
Mar 17 16:33:04 su kernel: Loaded prism54 driver, version 1.2
Mar 17 16:33:04 su kernel: PCI: Enabling device 0001:11:00.0 (0000 -> 0002)
Mar 17 16:33:04 su kernel: prism54: pci_set_mwi(pdev) succeeded
] ifup prism54-0 (fires up wpa_supplicant and tries to associate to local WPA AP)
Mar 17 16:33:54 su kernel: prism54-0: resetting device...
Mar 17 16:33:54 su kernel: prism54-0: uploading firmware...
Mar 17 16:33:54 su kernel: prism54-0: firmware version: 1.0.4.3
Mar 17 16:33:54 su kernel: prism54-0: firmware upload complete
Mar 17 16:33:54 su kernel: prism54-0: interface reset complete
Mar 17 16:33:55 su kernel: prism54-0: WPA IE Attachment was set
Mar 17 16:34:05 su kernel: prism54-0: no IPv6 routers present
Mar 17 16:34:08 su kernel: prism54-0: WPA IE Attachment was set
Mar 17 16:34:21 su kernel: prism54-0: WPA IE Attachment was set
Mar 17 16:34:34 su kernel: prism54-0: timeout waiting for mgmt response 300, triggering device
<repeat last two lies x 3>
Mar 17 16:35:14 su kernel: prism54-0: mgt_commit_list: failure. oid=19000004 err=1
Mar 17 16:35:14 su kernel: prism54-0: mgt_commit: failure
Mar 17 16:35:14 su kernel: prism54-0: WPA IE Attachment was set
<repeat last three lines>
Mar 17 16:35:30 su kernel: prism54-0: timeout waiting for mgmt response 300, triggering device
Mar 17 16:35:30 su kernel: prism54-0: mgt_commit_list: failure. oid=19000004 err=1
Mar 17 16:35:30 su kernel: prism54-0: mgt_commit: failure
Mar 17 16:35:30 su kernel: prism54-0: WPA IE Attachment was set
<repeat these four lines a lot>
Mar 17 16:37:40 su kernel: prism54-0: timeout waiting for mgmt response 300, triggering device
Mar 17 16:37:40 su kernel: prism54-0: timeout waiting for mgmt response 270, triggering device
Mar 17 16:37:40 su kernel: prism54-0: timeout waiting for mgmt response 240, triggering device
Mar 17 16:37:40 su kernel: prism54-0: timeout waiting for mgmt response 210, triggering device
Mar 17 16:37:41 su kernel: prism54-0: timeout waiting for mgmt response 180, triggering device
Mar 17 16:37:41 su kernel: prism54-0: timeout waiting for mgmt response 150, triggering device
Mar 17 16:37:41 su kernel: prism54-0: timeout waiting for mgmt response 120, triggering device
Mar 17 16:37:41 su kernel: prism54-0: timeout waiting for mgmt response 90, triggering device
Mar 17 16:37:41 su kernel: prism54-0: timeout waiting for mgmt response 60, triggering device
Mar 17 16:37:41 su kernel: prism54-0: timeout waiting for mgmt response 30, triggering device
Mar 17 16:37:41 su kernel: prism54-0: timeout waiting for mgmt response
<repeat above lines again>
Mar 17 16:37:51 su kernel: prism54-0: mgmt tx queue is still full
<lots of these until I shut down the interface>
Mar 17 16:39:25 su kernel: prism54-0: islpci_close ()
Bleh, that doesn't look healthy.
] rmmod prism54
Mar 17 16:43:26 su kernel: prism54-0: removing device
Mar 17 16:43:26 su kernel: Unloaded prism54 driver
Then, with the p54 code, patched with the patch you attached.
] modprobe prism54pci
Mar 17 16:48:56 su kernel: p54: LM86 firmware
Mar 17 16:48:58 su kernel: 0001:11:00.0 (prism54pci): Cannot read eeprom!
Mar 17 16:48:58 su kernel: prism54pci: probe of 0001:11:00.0 failed with error -22
Hmm, I guess the patch fixed the BUG_ON. ^_^
Removing the modules produced nothing in the kernel log.
] eject card
Mar 17 16:51:14 su kernel: pccard: card ejected from slot 0
Excellent. So that's fixed the BUG_ON and the hard lock.
Still fails to read an eeprom from my card though. I'm wondering if the crapspew
from the prism54 driver implies card or socket badness?
However, the hardmac driver is able to get a MAC address (with an OID query,
according to the code) and the MAC address is correct: 00:60:64:03:41:81
Is it worth dumping the purported eeprom to see if it's actually a valid
eeprom in a format unexpected by the code? (The card is very old now...)
>> (Albeit the hardmach driver never managed to WPA, and as of 2.6.20 still
>> doesn't, haven't tried the version in wireless-dev yet)
> Hardmac version in wireless-dev is the same thing. wireless-dev is just for
> mac80211 and cfg80211 code.
Ah, right. The changes I'm seeing are post-2.6.20 changes in linus'
tree. I rebuilt my prism54 module with them for the above.
>> So maybe the BUG isn't a problem with the p54 driver, but I'd appreciate
>> help with making it find the eeprom so it doesn't happen...
> I just found a leak in a probe error path. It might somehow cause the problem
> in the pci code. I've attached a patch to fix it.
> Thanks,
> -Michael Wu
> p54pci: Fix error path when eeprom read fails
Patch applied offset 11 lines...
--
-----------------------------------------------------------
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[email protected]
Of course Pacman didn't influence us as kids. If it did,
we'd be running around in darkened rooms, popping pills and
listening to repetitive music.
-- Kristian Wilson, Nintendo, Inc, 1989
License: http://creativecommons.org/licenses/by/2.1/au/
-----------------------------------------------------------
On Sat, Mar 17, 2007 at 02:44:49AM -0400, Michael Wu wrote:
> On Saturday 17 March 2007 02:15, Paul TBBle Hampson wrote:
>> Is it worth dumping the purported eeprom to see if it's actually a valid
>> eeprom in a format unexpected by the code? (The card is very old now...)
> Actually, the code doesn't check (but it does report) if parsing fails so a
> corrupted eeprom can't be the reason for probe failure. I'll get that fixed
> next week..
> So anyway, your card isn't even returning the eeprom data. Only thing I can
> think of is fiddling with the mdelay in that (p54p_read_eeprom) function
> (there's only one). Try making it bigger. That mdelay solved problems with
> eeprom reading on module reload but it's very close to the minimum delay
> needed there.
mdelay of 500 and 5000 didn't seem to help.
Would the result of any of the P54P_READs help? Or do they not produce
anything useful at this stage?
--
-----------------------------------------------------------
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[email protected]
Of course Pacman didn't influence us as kids. If it did,
we'd be running around in darkened rooms, popping pills and
listening to repetitive music.
-- Kristian Wilson, Nintendo, Inc, 1989
License: http://creativecommons.org/licenses/by/2.1/au/
-----------------------------------------------------------
On 3/17/07, Paul TBBle Hampson <[email protected]> wrote:
> On Sat, Mar 17, 2007 at 12:37:10AM -0400, Michael Wu wrote:
> > On Friday 16 March 2007 23:46, Paul TBBle Hampson wrote:
> >> The (built-in) bcm43xx-mac80211 driver works, but when I try to load a
> >> CardBus Atheros card I've got lying around with dadwifi-openhal, it
> >> fails with some sort of hardware error. (ie. it _might_ be a dodgey
> >> Cardbus port, although both cardbus cards used to work in this machine,
> >> using prism54 hardmac and the dadwifi with atheros hal driver
> >> respectively)
>
> > Can you rule out the port first? Load the fullmac driver first, bring it up &
> > down, unload it, and then try p54.
>
> OK, with the current prism54 as it appears in wireless-dev:
> Mar 17 16:32:41 su kernel: pccard: CardBus card inserted into slot 0
> ] modprobe prism54
> Mar 17 16:33:04 su kernel: Loaded prism54 driver, version 1.2
> Mar 17 16:33:04 su kernel: PCI: Enabling device 0001:11:00.0 (0000 -> 0002)
> Mar 17 16:33:04 su kernel: prism54: pci_set_mwi(pdev) succeeded
> ] ifup prism54-0 (fires up wpa_supplicant and tries to associate to local WPA AP)
> Mar 17 16:33:54 su kernel: prism54-0: resetting device...
> Mar 17 16:33:54 su kernel: prism54-0: uploading firmware...
> Mar 17 16:33:54 su kernel: prism54-0: firmware version: 1.0.4.3
> Mar 17 16:33:54 su kernel: prism54-0: firmware upload complete
> Mar 17 16:33:54 su kernel: prism54-0: interface reset complete
> Mar 17 16:33:55 su kernel: prism54-0: WPA IE Attachment was set
> Mar 17 16:34:05 su kernel: prism54-0: no IPv6 routers present
> Mar 17 16:34:08 su kernel: prism54-0: WPA IE Attachment was set
> Mar 17 16:34:21 su kernel: prism54-0: WPA IE Attachment was set
> Mar 17 16:34:34 su kernel: prism54-0: timeout waiting for mgmt response 300, triggering device
> <repeat last two lies x 3>
> Mar 17 16:35:14 su kernel: prism54-0: mgt_commit_list: failure. oid=19000004 err=1
> Mar 17 16:35:14 su kernel: prism54-0: mgt_commit: failure
> Mar 17 16:35:14 su kernel: prism54-0: WPA IE Attachment was set
> <repeat last three lines>
> Mar 17 16:35:30 su kernel: prism54-0: timeout waiting for mgmt response 300, triggering device
> Mar 17 16:35:30 su kernel: prism54-0: mgt_commit_list: failure. oid=19000004 err=1
> Mar 17 16:35:30 su kernel: prism54-0: mgt_commit: failure
> Mar 17 16:35:30 su kernel: prism54-0: WPA IE Attachment was set
> <repeat these four lines a lot>
> Mar 17 16:37:40 su kernel: prism54-0: timeout waiting for mgmt response 300, triggering device
FYI prism54 doesn't yet support WPA. There was a patch lying around
but I just have not had enough time to dedicate its integration.
Luis
On Sat, Mar 17, 2007 at 12:50:32AM -0400, Pavel Roskin wrote:
> On Sat, 2007-03-17 at 00:37 -0400, Michael Wu wrote:
>> On Friday 16 March 2007 23:46, Paul TBBle Hampson wrote:
> >> The (built-in) bcm43xx-mac80211 driver works, but when I try to load a
> >> CardBus Atheros card I've got lying around with dadwifi-openhal, it
> >> fails with some sort of hardware error. (ie. it _might_ be a dodgey
> >> Cardbus port, although both cardbus cards used to work in this machine,
> >> using prism54 hardmac and the dadwifi with atheros hal driver
> >> respectively)
>> Can you rule out the port first? Load the fullmac driver first, bring it up &
>> down, unload it, and then try p54.
> Oh, and I'm amazed that somebody is using dadwifi-openhal verify the
> hardware! It's in a pretty poor shape right now. It prints some
> warnings because it starts with channel 0. The interface can be brought
> up if you set a valid channel, and I think it might scan.
Well, since I'm at it:
Mar 17 17:28:19 su kernel: pccard: CardBus card inserted into slot 0
] modprobe ath_pci (dadwifi-openhal)
Mar 17 17:40:02 su kernel: ath_hal: OpenHAL loaded (AR5210, AR5211, AR5212, RF5110/1/2)
Mar 17 17:40:02 su kernel: ath_pci: 0.9.4.5-dadwifi (svn r2196)
Mar 17 17:40:02 su kernel: cannot find mode element.
Mar 17 17:40:02 su kernel: cannot find mode element.
Mar 17 17:40:02 su kernel: wmaster1: Selected rate control algorithm 'simple'
Mar 17 17:40:02 su kernel: wiphy7: mac 7.9 phy 4.5 radio 5.6
Mar 17 17:40:02 su kernel: wiphy7: Use hw queue 6 for CAB traffic
Mar 17 17:40:02 su kernel: wiphy7: Use hw queue 7 for beacons
Mar 17 17:40:02 su kernel: wiphy7: : mem=0xf3000000, irq=53
] iwconfig wlan1 channel 1
] ifup
lots of:
Mar 17 17:40:56 su kernel: ar5k_ar5212_set_txpower_limit: changing txpower to 9999
Mar 17 17:40:56 su kernel: ar5k_ar5212_txpower: invalid tx power: 9999
Mar 17 17:40:56 su kernel: ar5k_ar5212_set_txpower_limit: changing txpower to 0
during which it:
Mar 17 17:40:55 su kernel: wlan1: starting scan
Mar 17 17:40:56 su kernel: wlan1: scan completed
Mar 17 17:40:56 su kernel: wlan1: Initial auth_alg=0
Mar 17 17:40:56 su kernel: wlan1: authenticate with AP 00:14:6c:ed:c1:76
Mar 17 17:40:56 su kernel: rate_control_lowest_rate - no supported rates found
Mar 17 17:40:56 su kernel: wlan1: authenticate with AP 00:14:6c:ed:c1:76
Mar 17 17:40:56 su kernel: rate_control_lowest_rate - no supported rates found
Mar 17 17:40:56 su kernel: wlan1: authenticate with AP 00:14:6c:ed:c1:76
Mar 17 17:40:56 su kernel: rate_control_lowest_rate - no supported rates found
Mar 17 17:40:57 su kernel: wlan1: authentication with AP 00:14:6c:ed:c1:76 timed out
] if I ifup without iwconfig wlan1 channel 1:
Mar 17 17:28:58 su kernel: ar5k_ar5212_nic_wakeup: invalid radio frequency mode
Mar 17 17:28:58 su kernel: wiphy3: unable to reset hardware: 'Hardware I/O Error' (HAL status 2) (freq 0 flags 0x0)
] rmmod
Mar 17 17:44:20 su kernel: ar5k_ar5212_get_isr: 0x00000000
Mar 17 17:44:20 su kernel: ath_pci: driver unloaded
Mar 17 17:44:20 su kernel: ath_hal: driver unloaded
] modprobe ath_pci (dadwifi)
Mar 17 17:46:29 su kernel: ath_hal: 0.9.18.0 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413, REGOPS_FUNC)
Mar 17 17:46:29 su kernel: ath_pci: 0.9.4.5-dadwifi (svn r2195)
Mar 17 17:46:29 su kernel: ath_pci: unable to attach hardware: 'Hardware revision not supported' (HAL status 13)
Mar 17 17:46:32 su kernel: pccard: card ejected from slot 0
Mar 17 17:46:36 su kernel: pccard: CardBus card inserted into slot 0
Mar 17 17:46:36 su kernel: PCI: Enabling device 0001:11:00.0 (0000 -> 0002)
Mar 17 17:46:36 su kernel: cannot find mode element 0
Mar 17 17:46:36 su kernel: wmaster1: Selected rate control algorithm 'simple'
Mar 17 17:46:36 su kernel: wiphy9: mac 7.9 phy 4.5 radio 5.6
Mar 17 17:46:36 su kernel: wiphy9: Use hw queue 8 for CAB traffic
Mar 17 17:46:36 su kernel: wiphy9: Use hw queue 9 for beacons
Mar 17 17:46:36 su kernel: wiphy9: Atheros 5212: mem=0xf3000000, irq=53
] iwconfig wlan1 channel 1
] ifup
Mar 17 17:46:57 su kernel: wmaster1: Does not support passive scan, disabled
Mar 17 17:46:57 su kernel: wlan1: starting scan
Mar 17 17:46:58 su kernel: wlan1: scan completed
Mar 17 17:46:58 su kernel: wlan1: Initial auth_alg=0
Mar 17 17:46:58 su kernel: wlan1: authenticate with AP 00:14:6c:ed:c1:76
Mar 17 17:46:58 su kernel: wlan1: RX authentication from 00:14:6c:ed:c1:76 (alg=0 transaction=2 status=0)
Mar 17 17:46:58 su kernel: wlan1: authenticated
Mar 17 17:46:58 su kernel: wlan1: associate with AP 00:14:6c:ed:c1:76
Mar 17 17:46:58 su kernel: wlan1: RX AssocResp from 00:14:6c:ed:c1:76 (capab=0x51 status=0 aid=1)
Mar 17 17:46:58 su kernel: wlan1: associated
Mar 17 17:46:58 su kernel: wlan1: CTS protection enabled (BSSID=00:14:6c:ed:c1:76)
Mar 17 17:46:58 su kernel: device wlan1 entered promiscuous mode
Mar 17 17:46:58 su kernel: audit(1174114018.835:6): dev=wlan1 prom=256 old_prom=0 auid=4294967295
Mar 17 17:46:58 su kernel: audit(1174114018.835:6): arch=14 syscall=102 success=yes exit=0 a0=e a1=7fc42364 a2=1 a3=7fc42390 items=0 ppid=2278 pid=2284 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="guessnet-ifupdo" exe="/usr/sbin/guessnet" key=(null)
Mar 17 17:47:00 su kernel: wlan1: duplicate address detected!
] If I ifup without doing the iwconfig wlan1 channel 1:
Mar 17 17:34:23 su kernel: wiphy4: unable to reset hardware: '' (HAL status 0) (freq 0 flags 0x0)
] modprobe -r
Mar 17 17:34:50 su kernel: ath_pci: driver unloaded
Mar 17 17:34:50 su kernel: ath_hal: driver unloaded
Sometimes, when modprobing ath_pci from the dadwifi driver:
Mar 17 17:38:42 su kernel: ath_hal: 0.9.18.0 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413, REGOPS_FUNC)
Mar 17 17:38:42 su kernel: ath_pci: 0.9.4.5-dadwifi (svn r2195)
Mar 17 17:38:42 su kernel: ath_pci: unable to attach hardware: 'Hardware revision not supported' (HAL status 13)
but usually ejecting and reinserting the card while the driver's loaded
will fix that.
So in short, the channel-0 bug is the only thing keeping dadwifi from
working like a charm for me. And that's only a udev-rule away. ^_^
Meanwhile, dadwifi-openhal won't associate.
> And if you want to use madwifi-old-openhal for the purpose of testing,
> please use today's revision, or it will corrupt memory due to incorrect
> get_order() rounding that Linus has reverted in 2.6.21-rc4 (the fix is
> not in wireless-dev.git yet).
I've got that fix in my kernel already, it makes a 512MB powermac unbootable. ^_^
However, I'm not really interested in non-mac80211 drivers right now.
--
-----------------------------------------------------------
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[email protected]
Of course Pacman didn't influence us as kids. If it did,
we'd be running around in darkened rooms, popping pills and
listening to repetitive music.
-- Kristian Wilson, Nintendo, Inc, 1989
License: http://creativecommons.org/licenses/by/2.1/au/
-----------------------------------------------------------
On Sat, 2007-03-17 at 00:37 -0400, Michael Wu wrote:
> On Friday 16 March 2007 23:46, Paul TBBle Hampson wrote:
> > The (built-in) bcm43xx-mac80211 driver works, but when I try to load a
> > CardBus Atheros card I've got lying around with dadwifi-openhal, it
> > fails with some sort of hardware error. (ie. it _might_ be a dodgey
> > Cardbus port, although both cardbus cards used to work in this machine,
> > using prism54 hardmac and the dadwifi with atheros hal driver
> > respectively)
> >
> Can you rule out the port first? Load the fullmac driver first, bring it up &
> down, unload it, and then try p54.
Oh, and I'm amazed that somebody is using dadwifi-openhal verify the
hardware! It's in a pretty poor shape right now. It prints some
warnings because it starts with channel 0. The interface can be brought
up if you set a valid channel, and I think it might scan.
And if you want to use madwifi-old-openhal for the purpose of testing,
please use today's revision, or it will corrupt memory due to incorrect
get_order() rounding that Linus has reverted in 2.6.21-rc4 (the fix is
not in wireless-dev.git yet).
--
Regards,
Pavel Roskin
Quoting Michael Wu <[email protected]>:
> On Saturday 17 March 2007 00:50, Pavel Roskin wrote:
> > Oh, and I'm amazed that somebody is using dadwifi-openhal verify the
> > hardware! It's in a pretty poor shape right now. It prints some
> > warnings because it starts with channel 0. The interface can be brought
> > up if you set a valid channel, and I think it might scan.
> >
> Really? mac80211 should set the channel immediately after bringing the
> interface. If no channel is configured, it defaults to the first channel in
> the first mode that is registered.
Yes, really, but it's some internal sanity check, probably before the mac80211
layer is called.
--
Regards,
Pavel Roskin