associate, then "prism2sta_commsqual_defer: error fetching commsqual"

Discussion:

Josh Wyatt

2007-02-04 02:32:24 UTC

Greetings all,

I have an Acer Warplink 802.11b USB adapter that I received second-hand. I tried linux-wlan-ng 0.2.7 with it, with kernel 2.6.19.2.

The prism2_usb module loads successfully and reports:

Feb 3 20:22:41 atlantis kernel: [ 1267.488407] prism2usb_init: prism2_usb.o: 0.2.7 Loaded
Feb 3 20:22:41 atlantis kernel: [ 1267.488470] prism2usb_init: dev_info is: prism2_usb
Feb 3 20:22:41 atlantis kernel: [ 1267.497393] usbcore: registered new interface driver prism2_usb
Feb 3 20:22:41 atlantis net.agent[11886]: add event not handled
Feb 3 20:22:41 atlantis modprobe: FATAL: Module wlan0 not found.
Feb 3 20:22:41 atlantis kernel: [ 1267.876997] PDA Read from 0x007f0000 in EXTDS space.
Feb 3 20:22:41 atlantis kernel: [ 1267.882975] PDA Read from 0x007f0000 in EXTDS space.
Feb 3 20:22:41 atlantis kernel: [ 1267.926933] Writing 4096 bytes to ram @0x7e2ffe
<more writing messages snipped>
Feb 3 20:22:41 atlantis kernel: [ 1268.088685] ident: nic h/w: id=0x8026 1.0.0
Feb 3 20:22:41 atlantis kernel: [ 1268.090710] ident: pri f/w: id=0x15 1.1.2
Feb 3 20:22:41 atlantis kernel: [ 1268.092726] ident: sta f/w: id=0x1f 1.8.3
Feb 3 20:22:41 atlantis kernel: [ 1268.094707] MFI:SUP:role=0x00:id=0x01:var=0x01:b/t=1/1
Feb 3 20:22:41 atlantis kernel: [ 1268.096691] CFI:SUP:role=0x00:id=0x02:var=0x02:b/t=1/1
Feb 3 20:22:41 atlantis kernel: [ 1268.098685] PRI:SUP:role=0x00:id=0x03:var=0x01:b/t=1/4
Feb 3 20:22:41 atlantis kernel: [ 1268.100675] STA:SUP:role=0x00:id=0x04:var=0x01:b/t=1/15
Feb 3 20:22:41 atlantis kernel: [ 1268.102683] PRI-CFI:ACT:role=0x01:id=0x02:var=0x02:b/t=1/1
Feb 3 20:22:41 atlantis kernel: [ 1268.104669] STA-CFI:ACT:role=0x01:id=0x02:var=0x02:b/t=1/1
Feb 3 20:22:41 atlantis kernel: [ 1268.106672] STA-MFI:ACT:role=0x01:id=0x01:var=0x01:b/t=1/1
Feb 3 20:22:41 atlantis kernel: [ 1268.108678] Prism2 card SN: 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
Feb 3 20:22:46 atlantis wlan.agent[11879]: WLAN wlan0 brought up successfully.
Feb 3 20:22:46 atlantis wlan.agent[11879]: WLAN bringing up layer 3+ with /sbin/ifup
Feb 3 20:22:47 atlantis kernel: [ 1273.493326] linkstatus=CONNECTED
Feb 3 20:22:54 atlantis kernel: [ 1280.506745] hfa384x_usbctlx_complete_sync: CTLX[3] error: state(Request failed)
Feb 3 20:22:54 atlantis kernel: [ 1280.506752] prism2sta_commsqual_defer: error fetching commsqual

Note that association happens successfully, but a few seconds later, the card seems to fail.

Any ideas? I have a suspicion that the hardware is faulty. For example, after the above, the device disappears from the USB tree, and does not reappear after a reboot. Only removing and replacing the device "revives" it. But, the silly thing actually works for a few seconds!

Any help would be appreciated.

Thanks,
Josh

Chris Rankin

2007-02-04 11:29:14 UTC

Permalink

Post by Josh Wyatt
Any ideas? I have a suspicion that the hardware is faulty. For example, after the above, the
device disappears from the USB tree, and does not reappear after a reboot. Only removing and
replacing the device "revives" it. But, the silly thing actually works for a few seconds!
Any help would be appreciated.

Did you notice a lot of compiler warnings in hfa384x_usb.c? The prototype to one of the kernel's
callback functions changed in 2.6.19, and I'm not sure that vanilla 0.2.7 has the fix. (Or even if
it matters...) You can grab the fix from the SVN repository.

Another thing you could try is uploading station firmware 1.7.6 instead. Personally, I've never
had good results with the 1.8.x series of firmware.

Cheers,
Chris

___________________________________________________________
What kind of emailer are you? Find out today - get a free analysis of your email personality. Take the quiz at the Yahoo! Mail Championship.
http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk

Josh Wyatt

2007-02-04 13:50:09 UTC

Permalink

Post by Chris Rankin

I recompiled to see if they popped up and sure enough:
make[4]: Entering directory `/usr/src/linux-2.6.19.2-jdw2'^M
CC [M] /root/linux-wlan-ng-0.2.7/src/prism2/driver/prism2_usb.o^M
In file included from /root/linux-wlan-ng-0.2.7/src/prism2/driver/hfa384x_usb.c:209,^M
from /root/linux-wlan-ng-0.2.7/src/prism2/driver/prism2_usb.c:2:^M
/root/linux-wlan-ng-0.2.7/src//prism2/include/prism2/hfa384x.h:931: warning: 'packed' attribute ignored for field of type 'UINT8[]'^M
/root/linux-wlan-ng-0.2.7/src//prism2/include/prism2/hfa384x.h:937: warning: 'packed' attribute ignored for field of type 'UINT8[31u]'^M
/root/linux-wlan-ng-0.2.7/src//prism2/include/prism2/hfa384x.h:994: warning: 'packed' attribute ignored for field of type 'UINT8[5u]'^M
/root/linux-wlan-ng-0.2.7/src//prism2/include/prism2/hfa384x.h:1000: warning: 'packed' attribute ignored for field of type 'UINT8[33u]'^M
<lots snipped>

And lots for prism2dl.c:
gcc -I../../include -I../include -I/lib/modules/2.6.19.2-jdw2/build/include -D__LINUX_WLAN__ -c -o prism2dl.o prism2dl.c^M
In file included from prism2dl.c:77:^M
../include/prism2/hfa384x.h:931: warning: 'packed' attribute ignored for field of type 'UINT8[]'^M
../include/prism2/hfa384x.h:937: warning: 'packed' attribute ignored for field of type 'UINT8[31u]'^M
../include/prism2/hfa384x.h:994: warning: 'packed' attribute ignored for field of type 'UINT8[5u]'^M
<lots snipped>

I will try the SVN repo version and get back to you.

Post by Chris Rankin
Another thing you could try is uploading station firmware 1.7.6 instead. Personally, I've never
had good results with the 1.8.x series of firmware.

I had tried whatever firmware was on the card. I think 1.5.6. Same results. I'll try the SVN version first.

Post by Chris Rankin
Cheers,
Chris

Thanks,
Josh

Josh Wyatt

2007-02-04 14:52:55 UTC

Permalink

Post by Josh Wyatt

Post by Chris Rankin

<lots snipped>
I will try the SVN repo version and get back to you.

Same problem with this morning's svn (reports 0.2.8). Although I do note that it took almost a minute (59 seconds) to fail this time, instead of 7-15 seconds from previous attempts.

Feb 4 09:41:33 atlantis kernel: [47169.906389] prism2usb_init: prism2_usb.o: 0.2.8 Loaded
Feb 4 09:41:33 atlantis kernel: [47169.906715] prism2usb_init: dev_info is: prism2_usb
Feb 4 09:41:33 atlantis kernel: [47169.915598] usbcore: registered new interface driver prism2_usb
Feb 4 09:41:33 atlantis modprobe: FATAL: Module wlan0 not found.
Feb 4 09:41:33 atlantis net.agent[11037]: add event not handled
Feb 4 09:41:34 atlantis kernel: [47170.346495] PDA Read from 0x007f0000 in EXTDS space.
Feb 4 09:41:34 atlantis kernel: [47170.366454] PDA Read from 0x007f0000 in EXTDS space.
Feb 4 09:41:34 atlantis kernel: [47170.410414] Writing 4096 bytes to ram @0x7e2ffe
Feb 4 09:41:34 atlantis kernel: [47170.418414] Writing 4096 bytes to ram @0x7e3ffe
Feb 4 09:41:34 atlantis kernel: [47170.426402] Writing 4096 bytes to ram @0x7e4ffe
Feb 4 09:41:34 atlantis kernel: [47170.434388] Writing 4096 bytes to ram @0x7e5ffe
Feb 4 09:41:34 atlantis kernel: [47170.442376] Writing 4096 bytes to ram @0x7e6ffe
Feb 4 09:41:34 atlantis kernel: [47170.450377] Writing 4096 bytes to ram @0x7e7ffe
Feb 4 09:41:34 atlantis kernel: [47170.458339] Writing 4096 bytes to ram @0x7e8ffe
Feb 4 09:41:34 atlantis kernel: [47170.466407] Writing 4096 bytes to ram @0x7e9ffe
Feb 4 09:41:34 atlantis kernel: [47170.474339] Writing 4096 bytes to ram @0x7eaffe
Feb 4 09:41:34 atlantis kernel: [47170.482324] Writing 4096 bytes to ram @0x7ebffe
Feb 4 09:41:34 atlantis kernel: [47170.490314] Writing 4096 bytes to ram @0x7ecffe
Feb 4 09:41:34 atlantis kernel: [47170.498302] Writing 4096 bytes to ram @0x7edffe
Feb 4 09:41:34 atlantis kernel: [47170.506289] Writing 3010 bytes to ram @0x7eeffe
Feb 4 09:41:34 atlantis kernel: [47170.512280] Writing 416 bytes to ram @0x7efc20
Feb 4 09:41:34 atlantis kernel: [47170.514259] Writing 16 bytes to ram @0x7efdd0
Feb 4 09:41:34 atlantis kernel: [47170.516326] Writing 4044 bytes to ram @0x7f0800
Feb 4 09:41:34 atlantis kernel: [47170.524270] Writing 3288 bytes to ram @0x7fe000
Feb 4 09:41:34 atlantis kernel: [47170.572170] ident: nic h/w: id=0x8026 1.0.0
Feb 4 09:41:34 atlantis kernel: [47170.574168] ident: pri f/w: id=0x15 1.1.2
Feb 4 09:41:34 atlantis kernel: [47170.576179] ident: sta f/w: id=0x1f 1.8.3
Feb 4 09:41:34 atlantis kernel: [47170.578166] MFI:SUP:role=0x00:id=0x01:var=0x01:b/t=1/1
Feb 4 09:41:34 atlantis kernel: [47170.580159] CFI:SUP:role=0x00:id=0x02:var=0x02:b/t=1/1
Feb 4 09:41:34 atlantis kernel: [47170.582157] PRI:SUP:role=0x00:id=0x03:var=0x01:b/t=1/4
Feb 4 09:41:34 atlantis kernel: [47170.584158] STA:SUP:role=0x00:id=0x04:var=0x01:b/t=1/15
Feb 4 09:41:34 atlantis kernel: [47170.586161] PRI-CFI:ACT:role=0x01:id=0x02:var=0x02:b/t=1/1
Feb 4 09:41:34 atlantis kernel: [47170.588149] STA-CFI:ACT:role=0x01:id=0x02:var=0x02:b/t=1/1
Feb 4 09:41:34 atlantis kernel: [47170.590150] STA-MFI:ACT:role=0x01:id=0x01:var=0x01:b/t=1/1
Feb 4 09:41:34 atlantis kernel: [47170.592142] Prism2 card SN: 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
Feb 4 09:41:39 atlantis wlan.agent[11030]: WLAN wlan0 brought up successfully.
Feb 4 09:41:39 atlantis wlan.agent[11030]: WLAN bringing up layer 3+ with /sbin/ifup
Feb 4 09:41:39 atlantis kernel: [47176.025742] linkstatus=CONNECTED
Feb 4 09:42:38 atlantis kernel: [47234.983316] hfa384x_usbctlx_complete_sync: CTLX[3] error: state(Request failed)
Feb 4 09:42:38 atlantis kernel: [47234.983323] prism2sta_commsqual_defer: error fetching commsqual

I should add I'm not generating any traffic, etc on the link.

I went back in the mailing list archives and found a thread called 'prism2_usb on jvc lockup' which sounds similar to my problem. It seemed the consensus on that thread was other processes trying to snoop on the USB bus, such as hald. I have nothing else running on this system - just 2.6.19.2, sshd, init, cron.. Here's a typical ps -ef:

atlantis ~ # ps -ef
UID PID PPID C STIME TTY TIME CMD
root 1 0 1 09:50 ? 00:00:01 init [3]
root 2 1 0 09:50 ? 00:00:00 [ksoftirqd/0]
root 3 1 0 09:50 ? 00:00:00 [watchdog/0]
root 4 1 0 09:50 ? 00:00:00 [events/0]
root 5 1 0 09:50 ? 00:00:00 [khelper]
root 6 1 0 09:50 ? 00:00:00 [kthread]
root 46 6 0 09:50 ? 00:00:00 [kblockd/0]
root 47 6 0 09:50 ? 00:00:00 [kacpid]
root 164 6 0 09:50 ? 00:00:00 [ata/0]
root 165 6 0 09:50 ? 00:00:00 [ata_aux]
root 166 6 0 09:50 ? 00:00:00 [kseriod]
root 193 6 0 09:50 ? 00:00:00 [pdflush]
root 194 6 0 09:50 ? 00:00:00 [pdflush]
root 195 6 0 09:50 ? 00:00:00 [kswapd0]
root 196 6 0 09:50 ? 00:00:00 [aio/0]
root 862 6 0 09:50 ? 00:00:00 [kpsmoused]
root 865 6 0 09:50 ? 00:00:00 [kcryptd/0]
root 866 6 0 09:50 ? 00:00:00 [kmpathd/0]
root 867 6 0 09:50 ? 00:00:00 [ksnapd]
root 868 6 0 09:50 ? 00:00:00 [kmirrord]
root 883 6 0 09:50 ? 00:00:00 [kjournald]
root 1082 1 0 09:50 ? 00:00:00 /sbin/udevd --daemon
root 2548 6 0 09:50 ? 00:00:00 [ksuspend_usbd]
root 2551 6 0 09:50 ? 00:00:00 [khubd]
root 4466 1 0 09:50 ? 00:00:00 /usr/sbin/syslogd -m 0
root 4478 1 0 09:50 ? 00:00:00 /usr/sbin/klogd -c 3 -2
root 5721 6 0 09:51 ? 00:00:00 [khpsbpkt]
root 5749 6 0 09:51 ? 00:00:00 [knodemgrd_0]
root 7618 1 0 09:51 ? 00:00:00 /usr/sbin/sshd
root 7683 1 0 09:51 ? 00:00:00 /usr/sbin/cron
root 7750 1 0 09:51 ? 00:00:00 /usr/sbin/watchdog
root 7837 1 0 09:51 tty1 00:00:00 /sbin/agetty 38400 tty1 linux
root 7838 1 0 09:51 tty2 00:00:00 /sbin/agetty 38400 tty2 linux
root 7839 1 0 09:51 tty3 00:00:00 /sbin/agetty 38400 tty3 linux
root 7840 1 0 09:51 tty4 00:00:00 /sbin/agetty 38400 tty4 linux
root 7841 1 0 09:51 tty5 00:00:00 /sbin/agetty 38400 tty5 linux
root 7842 1 0 09:51 tty6 00:00:00 /sbin/agetty 38400 tty6 linux
root 7861 7618 0 09:51 ? 00:00:00 sshd: ***@pts/0
root 7873 7861 0 09:51 pts/0 00:00:00 -bash
root 7940 7873 0 09:51 pts/0 00:00:00 ps -ef

Thanks,
Josh

Josh Wyatt

2007-02-04 16:12:39 UTC

Permalink

Post by Josh Wyatt

Post by Chris Rankin

<lots snipped>
I will try the SVN repo version and get back to you.

Same problem with this morning's svn (reports 0.2.8). Although I do note that it took almost a minute (59 seconds) to fail this time, instead of 7-15 seconds from previous attempts.

Another datapoint. I also tried this on a completely different machine which has 0.2.0 running, with kernel 2.4.29 (Does that make me a luddite?). This machine is a compaq evo N600C with builtin wireless, which is an internal version of a prism2.5 USB card. It has been nice and stable for me for quite awhile.

I tested by disabling the internal wireless, then booting the machine and trying to bring up this external one.

Net result is the interface is initialized and configured successfully, but after a minute or two, the machine completely locks.

I'm starting to think this hardware is somehow broken. It was second-hand, after all. Any other thoughts? I tell you, getting wireless going happily on Linux is getting harder and harder.

Thanks,
Josh

Chris Rankin

2007-02-04 17:04:30 UTC

Permalink

Post by Josh Wyatt
Another datapoint. I also tried this on a completely different machine which has 0.2.0 running,
with kernel 2.4.29 (Does that make me a luddite?). This machine is a compaq evo N600C with
builtin wireless, which is an internal version of a prism2.5 USB card. It has been nice and
stable for me for quite awhile.

...

Post by Josh Wyatt
Net result is the interface is initialized and configured successfully, but after a minute or
two, the machine completely locks.

I wouldn't conclude that yet; the driver has changed considerably between 0.2.0 and 0.2.8, as has
the Linux USB stack between 2.4.x and 2.6.x. The fact that the *entire machine* locks with 0.2.0
suggests that you hit a nasty driver bug. Can you compile 0.2.8 on Linux 2.4.29?

Ideally, you would need to try a second "known good" Prism2 USB device in your existing machine to
prove that your current device is broken. Plugging your device into a Windows machine wouldn't
*necessarily* prove anything, although it would be a good indication of a broken device if it
failed under Windows too.

Cheers,
Chris

___________________________________________________________
New Yahoo! Mail is the ultimate force in competitive emailing. Find out more at the Yahoo! Mail Championships. Plus: play games and win prizes.
http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk

Josh Wyatt

2007-02-04 19:55:40 UTC

Permalink

Post by Chris Rankin

...

Post by Josh Wyatt
Net result is the interface is initialized and configured successfully, but after a minute or
two, the machine completely locks.

I was not able to successfully compile anything against my crufty old 2.4.29 tree. Instead I downloaded and built 2.4.34, and then tried compiling 0.2.8 against it.

With 0.2.8 make fails with:

make[2]: Entering directory `/usr/src/linux-wlan-ng-0.2.8/src/prism2'
set -e; for d in driver ridlist download; do make -C $d ; done
make[3]: Entering directory `/usr/src/linux-wlan-ng-0.2.8/src/prism2/driver'
cp /usr/src/linux-wlan-ng-0.2.8/src//p80211/Module*.symvers .
cp: cannot stat `/usr/src/linux-wlan-ng-0.2.8/src//p80211/Module*.symvers': No s
uch file or directory
make[3]: *** [default] Error 1
make[3]: Leaving directory `/usr/src/linux-wlan-ng-0.2.8/src/prism2/driver'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/usr/src/linux-wlan-ng-0.2.8/src/prism2'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/usr/src/linux-wlan-ng-0.2.8/src'
make: *** [all] Error 2

However, I successfully compiled 0.2.7 against the exact same linux-2.4.34 tree with no problems.

So, the past few minutes, I've been testing the internal (known good) USB interface, disconnecting it, connecting the Acer Warplink, testing it, etc.

Although it's only been up a few minutes, I feel the internal USB adapter is healthy and working well. [additional note just before hitting 'Send': The internal USB has been up 30 minutes so far with no issues]

The problematic Acer Warplink seems to fall off and immediately rejoin the USB bus occasionally, causing wlan0 to disappear.

Here's some *.debug from syslog. Note the "portstatus change" at 14:31:24:

Feb 4 14:29:39 creamsoda kernel: ident: nic h/w: id=0x8026 1.0.0
Feb 4 14:29:39 creamsoda kernel: ident: pri f/w: id=0x15 1.1.2
Feb 4 14:29:39 creamsoda kernel: ident: sta f/w: id=0x1f 1.5.6
Feb 4 14:29:39 creamsoda kernel: MFI:SUP:role=0x00:id=0x01:var=0x01:b/t=1/1
Feb 4 14:29:39 creamsoda kernel: CFI:SUP:role=0x00:id=0x02:var=0x02:b/t=1/1
Feb 4 14:29:39 creamsoda kernel: PRI:SUP:role=0x00:id=0x03:var=0x01:b/t=1/4
Feb 4 14:29:39 creamsoda kernel: STA:SUP:role=0x00:id=0x04:var=0x01:b/t=1/10
Feb 4 14:29:39 creamsoda kernel: PRI-CFI:ACT:role=0x01:id=0x02:var=0x02:b/t=1/1
Feb 4 14:29:39 creamsoda kernel: STA-CFI:ACT:role=0x01:id=0x02:var=0x02:b/t=1/1
Feb 4 14:29:39 creamsoda kernel: STA-MFI:ACT:role=0x01:id=0x01:var=0x01:b/t=1/1
Feb 4 14:29:39 creamsoda kernel: Prism2 card SN: 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
Feb 4 14:29:39 creamsoda kernel: wlan0 (WE) : Buffer for request 8B1B too small (0<6)
Feb 4 14:29:39 creamsoda kernel: wlan0 (WE) : Buffer for request 8B1D too small (0<6)
Feb 4 14:29:39 creamsoda kernel: usbctlx_rrid_completor_fn: RID len mismatch, rid=0xfcbe hlen=2 fwlen=-2
Feb 4 14:29:39 creamsoda kernel: p80211knetdev_hard_start_xmit: Tx attempt prior to association, frame dropped.
Feb 4 14:29:40 creamsoda kernel: linkstatus=CONNECTED
Feb 4 14:31:24 creamsoda kernel: hub.c: port 1, portstatus 101, change 2, 12 Mb/s
Feb 4 14:31:24 creamsoda kernel: hub.c: port 1 enable change, status 101
Feb 4 14:31:24 creamsoda kernel: hub.c: already running port 1 disabled by hub (EMI?), re-enabling...
Feb 4 14:31:24 creamsoda kernel: hub.c: port 1, portstatus 101, change 2, 12 Mb/s
Feb 4 14:31:24 creamsoda kernel: usb.c: USB disconnect on device 00:1d.1-1 address 2
Feb 4 14:31:24 creamsoda kernel: divert: freeing divert_blk for wlan0
Feb 4 14:31:24 creamsoda kernel: usb.c: kusbd: /sbin/hotplug remove 2

Then it immediately (within one second) rejoins the USB bus it seems:

Feb 4 14:31:25 creamsoda kernel: hub.c: port 1, portstatus 101, change 0, 12 Mb/s
Feb 4 14:31:25 creamsoda last message repeated 3 times
Feb 4 14:31:25 creamsoda kernel: hub.c: port 1, portstatus 103, change 0, 12 Mb/s
Feb 4 14:31:25 creamsoda kernel: hub.c: new USB device 00:1d.1-1, assigned address 3
Feb 4 14:31:25 creamsoda kernel: usb.c: kmalloc IF f602376c, numif 1
Feb 4 14:31:25 creamsoda kernel: usb.c: new device strings: Mfr=0, Product=0, SerialNumber=1
Feb 4 14:31:25 creamsoda kernel: usb.c: USB device number 3 default language ID 0x409

This happened twice.

Generally I was able to re-join the network with 'wlanctl-ng wlan0 lnxreq_ifstate ifstate=enable', etc after this.

When I tried a third time, I saw that the USB device stopped responding:

Feb 4 14:34:15 creamsoda kernel: hub.c: port 1, portstatus 101, change 2, 12 Mb/s
Feb 4 14:34:16 creamsoda last message repeated 3 times
Feb 4 14:34:16 creamsoda kernel: hub.c: port 1, portstatus 103, change 0, 12 Mb/s
Feb 4 14:34:16 creamsoda kernel: hub.c: new USB device 00:1d.1-1, assigned address 5
Feb 4 14:34:16 creamsoda kernel: usb.c: USB device not accepting new address=5 (error=-110)
Feb 4 14:34:16 creamsoda kernel: hub.c: port 1, portstatus 103, change 0, 12 Mb/s
Feb 4 14:34:16 creamsoda kernel: hub.c: new USB device 00:1d.1-1, assigned address 6
Feb 4 14:34:16 creamsoda kernel: usb.c: USB device not accepting new address=6 (error=-110)
Feb 4 14:34:16 creamsoda kernel: hub.c: port 2, portstatus 100, change 0, 12 Mb/s
Feb 4 14:34:16 creamsoda kernel: hub.c: port 1, portstatus 101, change 0, 12 Mb/s
Feb 4 14:34:16 creamsoda kernel: hub.c: port 2, portstatus 100, change 0, 12 Mb/s

Post by Chris Rankin
Ideally, you would need to try a second "known good" Prism2 USB device in your existing machine to
prove that your current device is broken.

I wish I had another prism2 USB adapter to test with. Technically the one inside my laptop is a USB adapter, but it is not removable (not in any way meaningful for use on another machine).

Post by Chris Rankin
Plugging your device into a Windows machine wouldn't
*necessarily* prove anything, although it would be a good indication of a broken device if it
failed under Windows too.

No windows machines in this house! I will contact the person who gave me this adapter and see if they had any issues with using it under windows.

Post by Chris Rankin
Cheers,
Chris

Any additional thoughts?

Thanks,
josh

Chris Rankin

2007-02-04 21:15:41 UTC

Permalink

Post by Josh Wyatt
Any additional thoughts?

Yes. Your primary firmware version is 1.1.2, whereas mine is:

ident: nic h/w: id=0x8010 1.0.0
ident: pri f/w: id=0x15 1.1.4
ident: sta f/w: id=0x1f 1.7.6

i.e. version 1.1.4. You could try upgrading your primary fimrware:

http://linux.junsun.net/intersil-prism/

BEWARE! NEVER UPLOAD PRIMARY FIRMWARE ALONE! ALWAYS UPLOAD PRIMARY AND STATIONARY FW TOGETHER.

Cheers,
Chris

___________________________________________________________
New Yahoo! Mail is the ultimate force in competitive emailing. Find out more at the Yahoo! Mail Championships. Plus: play games and win prizes.
http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk

Tormod Volden

2007-02-04 22:51:12 UTC

Permalink

Post by Chris Rankin
[...]
http://linux.junsun.net/intersil-prism/
BEWARE! NEVER UPLOAD PRIMARY FIRMWARE ALONE! ALWAYS UPLOAD PRIMARY AND STATIONARY FW TOGETHER.

Hi, and excuse me for chiming in, possibly without knowing too much about this:
Is it necessary to "flash" the firmware as described in your web link,
when you can just do the RAM upload with prism2dl instead (which
AFAICT from Josh's logs he is already using - that would be all the
"Writing" lines). If I have understood correctly, RAM upload is
relatively safe, but has to be done each time, whereas "flashing" is
more risky, but is done once for all. Josh just needs newer .hex
files, right?

Tormod

Josh Wyatt

2007-02-05 01:34:47 UTC

Permalink

Post by Tormod Volden

Post by Chris Rankin
[...]
http://linux.junsun.net/intersil-prism/
BEWARE! NEVER UPLOAD PRIMARY FIRMWARE ALONE! ALWAYS UPLOAD PRIMARY AND STATIONARY FW TOGETHER.

Is it necessary to "flash" the firmware as described in your web link,
when you can just do the RAM upload with prism2dl instead (which
AFAICT from Josh's logs he is already using - that would be all the
"Writing" lines). If I have understood correctly, RAM upload is
relatively safe, but has to be done each time, whereas "flashing" is
more risky, but is done once for all. Josh just needs newer .hex
files, right?
Tormod

You know, it's funny you mentioned this, because I can see that with my 2.4.34 kernel machine, the firmware images do NOT get downloaded to RAM.

I tried the instructions in the FAQ (Basically drop the firmware into the src/prism2 directory and rebuild/reinstall the driver) but it did not seem to make a difference.

However, with the 2.6.19.2 kernel machine, they do indeed.

Thanks,
Josh

Chris Rankin

2007-02-05 01:43:26 UTC

Permalink

Post by Tormod Volden
Is it necessary to "flash" the firmware as described in your web link,
when you can just do the RAM upload with prism2dl instead (which
AFAICT from Josh's logs he is already using - that would be all the
"Writing" lines).

You can RAM upload the station firmware, but you need to flash the primary firmware. So what I'm
suggesting is that Josh flash the primary firmware to 1.1.4 and the station firmware to 1.5.6
(still). Then he can RAM upload the station firmware to 1.7.6 when he plugs the adapter into his
machine.

Cheers,
Chris

___________________________________________________________
Web email has come of age. Don't settle for less than the All New Yahoo! Mail http://uk.docs.yahoo.com/nowyoucan.html

Chris Rankin

2007-02-05 17:21:42 UTC

Permalink

Can someone guide me on the exact invocation for prism2dl to first extract the existing firmware
images, then reflash with a newer primary?

In fact, I'll repeat that: you should *definitely* use WinUpdate.exe, because I have no idea which
primary firmware file is appropriate for your hardware:

Feb 3 20:22:41 atlantis kernel: [ 1268.088685] ident: nic h/w: id=0x8026 1.0.0
Feb 3 20:22:41 atlantis kernel: [ 1268.090710] ident: pri f/w: id=0x15 1.1.2
Feb 3 20:22:41 atlantis kernel: [ 1268.092726] ident: sta f/w: id=0x1f 1.8.3

The key number for identifying your underlying hardware is the "id=0x8026". However, I'm *fairly*
confident that you will want su010506.hex for your station (secondary) firmware.

Cheers,
Chris

___________________________________________________________
New Yahoo! Mail is the ultimate force in competitive emailing. Find out more at the Yahoo! Mail Championships. Plus: play games and win prizes.
http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk

Solomon Peachy

2007-02-05 20:25:34 UTC

Permalink

Post by Chris Rankin
In fact, I'll repeat that: you should *definitely* use WinUpdate.exe, because I have no idea which
Feb 3 20:22:41 atlantis kernel: [ 1268.088685] ident: nic h/w: id=0x8026 1.0.0
Feb 3 20:22:41 atlantis kernel: [ 1268.090710] ident: pri f/w: id=0x15 1.1.2
Feb 3 20:22:41 atlantis kernel: [ 1268.092726] ident: sta f/w: id=0x1f 1.8.3

Hardware ID 8026 uses the POxxyyzz.HEX firmware, and the SUxxyyzz.HEX secondary
firmware.

Primary firmware 1.1.4 fixes a problem with the hardware not restarting when a RAM
download is complete. 1.1.3 fixes enumeration problems and potential errors when
flashing new firmware.

But to echo Chris's recommendation, use the WinUpdate tool instead of prism2dl if
at all possible. Flashing USB prism2 widgets is tricky, and there's no way to
recover if something goes wrong.

- Solomon

--
Solomon Peachy ***@linux-wlan.com
AbsoluteValue Systems http://www.linux-wlan.com
721-D North Drive +1 (321) 259-0737 (office)
Melbourne, FL 32934 +1 (321) 259-0286 (fax)