OESF Portables Forum
Everything Else => Zaurus Distro Support and Discussion => Distros, Development, and Model Specific Forums => Archived Forums => Angstrom & OpenZaurus => Topic started by: mscdex on August 15, 2005, 05:08:49 am
-
I just installed OZ/opie 3.5.3 today (coming from stock sharp rom). The problem I'm having is I cannot get my Socket card to be recognized by OZ. I know the card works, as it worked with the spectrum drivers when I was using the sharp rom.
I've searched the OZ forums and could not find anything that would help me, seems like it's working out of the box for most people. But not for me for some reason
When I do a cardctl ident I get:
Socket 0:
product info: "Socket", "CF+ LP WLAN Card Rev A", "1.00"
manfid: 0x0104, 0x0001
function: 6 (network)
Socket 1:
no product info available
And when I do a cardctl status I get:
Socket 0:
3.3V 16-bit PC Card
function 0: [ready]
Socket 1:
no card
When I do an ifconfig, only the local loopback and the usbd0 are listed.
I have even tried installing the orinoco-modules-cs package and still no go.
Do I need to list some sort of log output or anything that might help someone figure out what's going wrong?
-
I just installed OZ/opie 3.5.3 the other day (coming from stock sharp rom). The problem I'm having is I cannot get my Socket card to be recognized by OZ. I know the card works, as it worked with the spectrum24 drivers when I was using the sharp rom.
I've searched the OZ forums and could not find anything that would help me, seems like it's working out of the box for most people. But not for me for some reason.
When I do a cardctl ident I get:
Socket 0:
product info: "Socket", "CF+ LP WLAN Card Rev A", "1.00"
manfid: 0x0104, 0x0001
function: 6 (network)
Socket 1:
no product info available
And when I do a cardctl status I get:
Socket 0:
3.3V 16-bit PC Card
function 0: [ready]
Socket 1:
no card
When I do an ifconfig, only the local loopback and the usbd0 are listed (and the irda interface when i have it enabled).
I have even tried installing the orinoco-modules-cs package and still no go.
After a number of reboots on the zaurus and trying various things like adding an entry in the hostap_cs.conf file, reinstalling orinoco-modules and/or orinoco-modules-cs, and even installing the spectrum24 driver, still nothing is working.
I'm fairly new to the zaurus and have tried everything I can think of. Should I be reflashing it or formatting the RAM and reflashing?
Or is this all because i'm on a 5600, as I read that there are/were very little testers for OZ on poodle?
Would I need to list some sort of log output or anything that might help someone figure out what's going wrong?
-
The 5600 seems to be the only model where it doesn't work out of the box. What does logread tell after card insertion? What does lsmod tell?
-
lsmod gives me:
Module Size Used by Tainted: P
orinoco 37092 0 (unused)
hermes 5384 0 [orinoco]
rfcomm 33488 0 (autoclean)
l2cap 17028 2 (autoclean) [rfcomm]
bluez 32616 1 (autoclean) [rfcomm l2cap]
sharp_mmcsd_m 26200 2
pxa_bi 20028 0 (unused)
net_fd 25012 1
usbdcore 30424 0 [pxa_bi net_fd]
Here's the part from the logread when I inserted the card after letting the Z boot up:
Aug 16 06:46:12 zaurus daemon.info cardmgr[683]: socket 0: Socket Communications CF+ LP WLAN Card
Aug 16 06:46:12 zaurus daemon.info cardmgr[683]: executing: 'modprobe hermes 2>&1'
Aug 16 06:46:12 zaurus daemon.info cardmgr[683]: + Using /lib/modules/2.4.18-rmk7-pxa3-embedix/net/hermes.o
Aug 16 06:46:12 zaurus user.debug kernel: orinoco.c 0.13e (David Gibson <hermes@gibson.dropbear.id.au> and others)
Aug 16 06:46:12 zaurus daemon.info cardmgr[683]: executing: 'modprobe orinoco 2>&1'
Aug 16 06:46:12 zaurus daemon.info cardmgr[683]: + Using /lib/modules/2.4.18-rmk7-pxa3-embedix/net/orinoco.o
Aug 16 06:46:12 zaurus daemon.info cardmgr[683]: executing: 'modprobe spectrum_cs 2>&1'
Aug 16 06:46:12 zaurus daemon.info cardmgr[683]: + modprobe: module spectrum_cs not found.
Aug 16 06:46:12 zaurus daemon.info cardmgr[683]: + modprobe: failed to load module spectrum_cs
Aug 16 06:46:12 zaurus daemon.notice cardmgr[683]: modprobe exited with status 1
Aug 16 06:46:12 zaurus daemon.notice cardmgr[683]: module /lib/modules/2.4.18-rmk7-pxa3-embedix/pcmcia/spectrum_cs.o not available
Aug 16 06:46:13 zaurus daemon.err cardmgr[683]: get dev info on socket 0 failed: Resource temporarily unavailable
I hope that helps. Let me know if I can do anything else to help out.
-
Any ideas?
Is it something on my end that I can fix, or is it something in the OZ poodle build?
-
module /lib/modules/2.4.18-rmk7-pxa3-embedix/pcmcia/spectrum_cs.o not available
Sounds like your orinoco-modules package is broken. spectrum_cs is supposed to be part of it. Try to reinstall it.
-
module /lib/modules/2.4.18-rmk7-pxa3-embedix/pcmcia/spectrum_cs.o not available
Sounds like your orinoco-modules package is broken. spectrum_cs is supposed to be part of it. Try to reinstall it.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=92447\"][{POST_SNAPBACK}][/a][/div]
Reinstalled it and orinoco-modules-cs too, and still no dice, same logread output.
-
Then orinoco-modules is broken for poodle. This stuff happens when stuff is blindly compiled.
-
Then orinoco-modules is broken for poodle. This stuff happens when stuff is blindly compiled.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=92553\"][{POST_SNAPBACK}][/a][/div]
I found out what was going wrong. I had to redownload the orinoco-modules and orinoco-modules-cs packages directly onto the zaurus somewhere and install right from the device (rather than from Qtopa Desktop).
As soon as I did that, and a little meddling I was able to get lights blinking on the card and got network access.
Only problem I'm having now is.... I am unable to use my modem's dns server on my zaurus. It doesn't resolve when I have it in there. My modem's ip is 192.168.0.1. I'm wondering if the usbd0 interface is interfering because it's ip is 192.168.129.201. So maybe it's trying to find it on the usbd0 interface instead of eth0?
If that is the case, how can I correct that?
-
This is the sort of thing you should start a new thread for...
Anwyay, are you saying that when your Z is plugged in you can't access DNS on the Z, or on the desktop box?
If the former, can you ping anything? If not look into setting up some routes on the desktop box, if the latter, I'm not sure, but again I imagine it's to do with your routeing,
Si
-
This is the sort of thing you should start a new thread for...
Anwyay, are you saying that when your Z is plugged in you can't access DNS on the Z, or on the desktop box?
If the former, can you ping anything? If not look into setting up some routes on the desktop box, if the latter, I'm not sure, but again I imagine it's to do with your routeing,
Si
[div align=\"right\"][a href=\"index.php?act=findpost&pid=92724\"][{POST_SNAPBACK}][/a][/div]
I mean when I have my Z out of the cradle and is connected to my wifi network, I cannot resolve any domain names/hostnames. However, I can ping the appropriately resolved IP address from my Z. This is with the DNS server set as my DSL modem, 192.168.0.1 (This is how all my other PCs are setup).
But if I change the DNS server to some external internet IP (one from my ISP), everything resolves correctly.
-
Interesting. No idea I'm afraid.
Strange that your other machines have the cable modem set as their DNS server. Can you not just leave your Z with the external IP address (as it works)?
Si
-
You have the same card I do.
With Hentges image, I can get Wellenreiter to work - pretty neat - although after running for some period of time - about 30 minutes to an hour it will lock up. (Light still flashes on the socket unit).
ifconfig shows the eth0 interface running - but the curious thing is that the MAX address is wrong. Only two of the 6 hex digits are correct.
Any attempt to run iwconfig immediately locks up the unit.
I manually added the necessary entries to /etc/network/interfaces.
For grins, I added the exact text and manfid to the various pcmcia config files did not seem to help.
From the various posts, I get the impression that the problem is the orinoco module that is not "patched" is in the kernel - and this has some sort of bug.
If I get it figured out, I will post the details.
I also get the following errors (dmesg). You might check at see if you get the same problem:
rinoco.c 0.13e (David Gibson <hermes@gibson.dropbear.id.au> and others)
spectrum_cs.c 0.4.2 (Pavel Roskin <proski@gnu.org> and others)
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfd20) does not match type (0x0021)
hermes @ IO 0xf6000000: Truncating LTV record from 129544 to 8 bytes. (rid=0xfd20, len=0xfd05)
eth0: Station identity 0002:0001:4920:2000
eth0: Looks like a Lucent/Agere firmware version 18720.8192
eth0: Ad-hoc demo mode supported
eth0: IEEE standard IBSS ad-hoc mode supported
eth0: WEP supported, 104-bit key
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc01) does not match type (0x5e00)
hermes @ IO 0xf6000000: Truncating LTV record from 129030 to 6 bytes. (rid=0xfc01, len=0xfc04)
eth0: MAC address 14:1C:01:00:20:49
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc0e) does not match type (0x7200)
hermes @ IO 0xf6000000: Truncating LTV record from 129058 to 34 bytes. (rid=0xfc0e, len=0xfc12)
eth0: Station name "m I"
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfd10) does not match type (0x72ff)
hermes @ IO 0xf6000000: Truncating LTV record from 129538 to 2 bytes. (rid=0xfd10, len=0xfd02)
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc06) does not match type (0x72ff)
hermes @ IO 0xf6000000: Truncating LTV record from 129022 to 2 bytes. (rid=0xfc06, len=0xfc00)
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc83) does not match type (0x722b)
hermes @ IO 0xf6000000: Truncating LTV record from 129026 to 2 bytes. (rid=0xfc83, len=0xfc02)
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc25) does not match type (0x722b)
hermes @ IO 0xf6000000: Truncating LTV record from 129022 to 2 bytes. (rid=0xfc25, len=0xfc00)
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc0c) does not match type (0x7264)
hermes @ IO 0xf6000000: Truncating LTV record from 129026 to 2 bytes. (rid=0xfc0c, len=0xfc02)
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc0d) does not match type (0x7264)
hermes @ IO 0xf6000000: Truncating LTV record from 129026 to 2 bytes. (rid=0xfc0d, len=0xfc02)
eth0: ready
eth0: index 0x01: Vcc 3.3, irq 39, io 0xf6000000-0xf6000047
-
Then orinoco-modules is broken for poodle. This stuff happens when stuff is blindly compiled.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=92553\"][{POST_SNAPBACK}][/a][/div]
I found out what was going wrong. I had to redownload the orinoco-modules and orinoco-modules-cs packages directly onto the zaurus somewhere and install right from the device (rather than from Qtopa Desktop).
[div align=\"right\"][a href=\"index.php?act=findpost&pid=92573\"][{POST_SNAPBACK}][/a][/div]
mscdex,
(BTW - is your moniker from the old CDROM driver?).
I am currently trying Hentges image. Seems to be working MUCH better on Poodle that the standard distribution although I still have occasional suspend issues.
Regarding the Socket WLAN card (which I used to use under the Sharp ROM):
I can get Mickey's Wellenreiter to run nicely with my socket card which is identical to yours - but as you found, if I even try to call the opie-network applet or execute any form of the iwconfig command, it totally locks up (with the card still flashing).
I get the following errors in dmsg:
orinoco.c 0.13e (David Gibson <hermes@gibson.dropbear.id.au> and others)
spectrum_cs.c 0.4.2 (Pavel Roskin <proski@gnu.org> and others)
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfd20) does not match type (0x0021)
hermes @ IO 0xf6000000: Truncating LTV record from 129544 to 8 bytes. (rid=0xfd20, len=0xfd05)
eth0: Station identity 0002:0001:4920:2000
eth0: Looks like a Lucent/Agere firmware version 18720.8192
eth0: Ad-hoc demo mode supported
eth0: IEEE standard IBSS ad-hoc mode supported
eth0: WEP supported, 104-bit key
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc01) does not match type (0x5e00)
hermes @ IO 0xf6000000: Truncating LTV record from 129030 to 6 bytes. (rid=0xfc01, len=0xfc04)
eth0: MAC address 14:1C:01:00:20:49
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc0e) does not match type (0x7200)
hermes @ IO 0xf6000000: Truncating LTV record from 129058 to 34 bytes. (rid=0xfc0e, len=0xfc12)
eth0: Station name "m I"
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfd10) does not match type (0x72ff)
hermes @ IO 0xf6000000: Truncating LTV record from 129538 to 2 bytes. (rid=0xfd10, len=0xfd02)
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc06) does not match type (0x72ff)
hermes @ IO 0xf6000000: Truncating LTV record from 129022 to 2 bytes. (rid=0xfc06, len=0xfc00)
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc83) does not match type (0x722b)
hermes @ IO 0xf6000000: Truncating LTV record from 129026 to 2 bytes. (rid=0xfc83, len=0xfc02)
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc25) does not match type (0x722b)
hermes @ IO 0xf6000000: Truncating LTV record from 129022 to 2 bytes. (rid=0xfc25, len=0xfc00)
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc0c) does not match type (0x7264)
hermes @ IO 0xf6000000: Truncating LTV record from 129026 to 2 bytes. (rid=0xfc0c, len=0xfc02)
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc0d) does not match type (0x7264)
hermes @ IO 0xf6000000: Truncating LTV record from 129026 to 2 bytes. (rid=0xfc0d, len=0xfc02)
eth0: ready
eth0: index 0x01: Vcc 3.3, irq 39, io 0xf6000000-0xf6000047
From everything I have seen here and elsewhere, it is apparently a bad orinoco module in the kernel.
Can you tell me exactly which one(s) you found that got you at least to the "ping" stage?
Thanks
-
You have the same card I do.
With Hentges image, I can get Wellenreiter to work - pretty neat - although after running for some period of time - about 30 minutes to an hour it will lock up. (Light still flashes on the socket unit).
ifconfig shows the eth0 interface running - but the curious thing is that the MAX address is wrong. Only two of the 6 hex digits are correct.
Any attempt to run iwconfig immediately locks up the unit.
I manually added the necessary entries to /etc/network/interfaces.
For grins, I added the exact text and manfid to the various pcmcia config files did not seem to help.
From the various posts, I get the impression that the problem is the orinoco module that is not "patched" is in the kernel - and this has some sort of bug.
If I get it figured out, I will post the details.
I also get the following errors (dmesg). You might check at see if you get the same problem:
rinoco.c 0.13e (David Gibson <hermes@gibson.dropbear.id.au> and others)
spectrum_cs.c 0.4.2 (Pavel Roskin <proski@gnu.org> and others)
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfd20) does not match type (0x0021)
hermes @ IO 0xf6000000: Truncating LTV record from 129544 to 8 bytes. (rid=0xfd20, len=0xfd05)
eth0: Station identity 0002:0001:4920:2000
eth0: Looks like a Lucent/Agere firmware version 18720.8192
eth0: Ad-hoc demo mode supported
eth0: IEEE standard IBSS ad-hoc mode supported
eth0: WEP supported, 104-bit key
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc01) does not match type (0x5e00)
hermes @ IO 0xf6000000: Truncating LTV record from 129030 to 6 bytes. (rid=0xfc01, len=0xfc04)
eth0: MAC address 14:1C:01:00:20:49
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc0e) does not match type (0x7200)
hermes @ IO 0xf6000000: Truncating LTV record from 129058 to 34 bytes. (rid=0xfc0e, len=0xfc12)
eth0: Station name "m I"
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfd10) does not match type (0x72ff)
hermes @ IO 0xf6000000: Truncating LTV record from 129538 to 2 bytes. (rid=0xfd10, len=0xfd02)
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc06) does not match type (0x72ff)
hermes @ IO 0xf6000000: Truncating LTV record from 129022 to 2 bytes. (rid=0xfc06, len=0xfc00)
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc83) does not match type (0x722b)
hermes @ IO 0xf6000000: Truncating LTV record from 129026 to 2 bytes. (rid=0xfc83, len=0xfc02)
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc25) does not match type (0x722b)
hermes @ IO 0xf6000000: Truncating LTV record from 129022 to 2 bytes. (rid=0xfc25, len=0xfc00)
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc0c) does not match type (0x7264)
hermes @ IO 0xf6000000: Truncating LTV record from 129026 to 2 bytes. (rid=0xfc0c, len=0xfc02)
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc0d) does not match type (0x7264)
hermes @ IO 0xf6000000: Truncating LTV record from 129026 to 2 bytes. (rid=0xfc0d, len=0xfc02)
eth0: ready
eth0: index 0x01: Vcc 3.3, irq 39, io 0xf6000000-0xf6000047
[div align=\"right\"][a href=\"index.php?act=findpost&pid=92818\"][{POST_SNAPBACK}][/a][/div]
Forgot I still had this topic open. The problem I was having ended up being I was trying to install/reinstall the orinoco-modules and orinoco-modules-cs packages through Qtopia Desktop. As soon as I installed them right from the device itself, things worked fine for me.
-
Forgot I still had this topic open. The problem I was having ended up being I was trying to install/reinstall the orinoco-modules and orinoco-modules-cs packages through Qtopia Desktop. As soon as I installed them right from the device itself, things worked fine for me.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=92876\"][{POST_SNAPBACK}][/a][/div]
Hmmm, that is not my issue because Hentges image comes with them installed.
-
Forgot I still had this topic open. The problem I was having ended up being I was trying to install/reinstall the orinoco-modules and orinoco-modules-cs packages through Qtopia Desktop. As soon as I installed them right from the device itself, things worked fine for me.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=92876\"][{POST_SNAPBACK}][/a][/div]
Hmmm, that is not my issue because Hentges image comes with them installed.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=92894\"][{POST_SNAPBACK}][/a][/div]
BTW, I re-installed the Orinoco from the 3.5.3 feed (this seemed to be what you were saying) from the machine/Poodle directory and now I get a exception dump everytime I insert the card:
orinoco.c 0.13e (David Gibson <hermes@gibson.dropbear.id.au> and others)
spectrum_cs.c 0.4.2 (Pavel Roskin <proski@gnu.org> and others)
Unable to handle kernel paging request at virtual address 000e0031
pgd = c1090000
*pgd = a108f001, *pmd = a108f001, *pte = 00000000, *ppte = 00000000
Internal error: Oops: ffffffff
CPU: 0
pc : [<c39d67e0>] lr : [<c00f2364>] Tainted: P
sp : c1b4bc20 ip : 000e0001 fp : c1b4bc34
r10: c032ba60 r9 : 0001bf90 r8 : 00000000
r7 : 00000000 r6 : c1b4bcc4 r5 : c39e0a14 r4 : 000000bc
r3 : 00000000 r2 : c1210800 r1 : c01bff4a r0 : c1210800
Flags: nzCv IRQs on FIQs on Mode SVC_32 Segment user
Control: 197F Table: A1090000 DAC: 00000015 PID: 0
Process cardmgr (pid: 1261, stackpage=c1b4b000)
Stack: (0xc1b4bc10 to 0xc1b4c000)
So that was definitely downhill - I presume that Hentges ROM already had a new version.
-
I think I found something ...
Hentges image, Poodle, Socket WLAN,
Noticed this error in logread and tried to execute directly from command line:
root@poodle:/etc/pcmcia# hostap_fw_load "eth0"
Host AP driver data for device eth0 not found in procfs.
Now if I can just find what procfs it is referring to ...
This is from logread:
....
Jul 29 14:20:39 poodle user.warn kernel: hermes @ IO 0xf6000000: Truncating LTV record from 129030 to 6 bytes. (rid=0xfc01, len=0xfc04)
Jul 29 14:20:39 poodle user.debug kernel: eth0: MAC address 14:1C:01:00:02:88
Jul 29 14:20:39 poodle user.warn kernel: hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc0e) does not match type (0x7200)
....
Jul 29 14:20:39 poodle user.warn kernel: hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc0d) does not match type (0x7264)
Jul 29 14:20:39 poodle user.warn kernel: hermes @ IO 0xf6000000: Truncating LTV record from 129026 to 2 bytes. (rid=0xfc0d, len=0xfc02)
Jul 29 14:20:39 poodle user.debug kernel: eth0: ready
Jul 29 14:20:39 poodle user.debug kernel: eth0: index 0x01: Vcc 3.3, irq 39, io 0xf6000000-0xf6000047
Jul 29 14:20:40 poodle daemon.info cardmgr[3528]: executing: './network start eth0 2>&1'
Jul 29 14:20:40 poodle daemon.info cardmgr[3528]: + Invalid command : reset
Jul 29 14:20:41 poodle daemon.info cardmgr[3528]: + Host AP driver data for device eth0 not found in procfs.
Jul 29 14:20:41 poodle daemon.info cardmgr[3528]: + run-parts: /etc/network/if-pre-up.d/hostap-fw-load exited with return code 1: Success
root@poodle:/media/cf/upgrades#
The other weird part is the mis-interpretation of the MAC address, it is really:
MAC 00 A0 F8 5E 14 1C
instead of the
MAC address 14:1C:01:00:02:88 that is shows above
-
Then orinoco-modules is broken for poodle. This stuff happens when stuff is blindly compiled.
[div align=\"right\"][{POST_SNAPBACK}][/a][/div] (http://index.php?act=findpost&pid=92553\")
I found out what was going wrong. I had to redownload the orinoco-modules and orinoco-modules-cs packages directly onto the zaurus somewhere and install right from the device (rather than from Qtopa Desktop).
As soon as I did that, and a little meddling I was able to get lights blinking on the card and got network access.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=92573\"][{POST_SNAPBACK}][/a][/div]
I too am having the same problem, though I copied the orinoco-modules and orinoco-modules-cs install files to my CF card and ran ipkg from the console, it still says it's missing spectrum_cs from the modules/2.x../pcmcia directory. What did you do to resolve the missing file?
I downloaded the 0.13e-r3 files from [a href=\"http://openzaurus.org/official/unstable/3.5.3/feed/machine/poodle/]http://openzaurus.org/official/unstable/3....machine/poodle/[/url].
before installing them I got an unsupported card, afterwards, I got the proper card name, but was missing the spectrum_cs card
-
Then orinoco-modules is broken for poodle. This stuff happens when stuff is blindly compiled.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=92553\"][{POST_SNAPBACK}][/a][/div]
I found out what was going wrong. I had to redownload the orinoco-modules and orinoco-modules-cs packages directly onto the zaurus somewhere and install right from the device (rather than from Qtopa Desktop).
As soon as I did that, and a little meddling I was able to get lights blinking on the card and got network access.
Only problem I'm having now is.... I am unable to use my modem's dns server on my zaurus. It doesn't resolve when I have it in there. My modem's ip is 192.168.0.1. I'm wondering if the usbd0 interface is interfering because it's ip is 192.168.129.201. So maybe it's trying to find it on the usbd0 interface instead of eth0?
If that is the case, how can I correct that?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=92573\"][{POST_SNAPBACK}][/a][/div]
where did you get the orinocos module? I got the same issue here (no spectrum24_cs found)
Thanks
-
where did you get the orinocos module?
In the 3.5.3 machine/poodle feed.
-
where did you get the orinocos module?
In the 3.5.3 machine/poodle feed.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=95266\"][{POST_SNAPBACK}][/a][/div]
I downloaded and installed them...restarted pcmcia services, and while my card seems to be detected properly. there is the spectrum_cs.o file in net/ but it seem to expect it in pcmcia/ so I copied it over, and recived a kernel oops for my trouble
-
Then orinoco-modules is broken for poodle. This stuff happens when stuff is blindly compiled.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=92553\"][{POST_SNAPBACK}][/a][/div]
I found out what was going wrong. I had to redownload the orinoco-modules and orinoco-modules-cs packages directly onto the zaurus somewhere and install right from the device (rather than from Qtopa Desktop).
[div align=\"right\"][a href=\"index.php?act=findpost&pid=92573\"][{POST_SNAPBACK}][/a][/div]
mscdex,
(BTW - is your moniker from the old CDROM driver?).
I am currently trying Hentges image. Seems to be working MUCH better on Poodle that the standard distribution although I still have occasional suspend issues.
Regarding the Socket WLAN card (which I used to use under the Sharp ROM):
I can get Mickey's Wellenreiter to run nicely with my socket card which is identical to yours - but as you found, if I even try to call the opie-network applet or execute any form of the iwconfig command, it totally locks up (with the card still flashing).
I get the following errors in dmsg:
orinoco.c 0.13e (David Gibson <hermes@gibson.dropbear.id.au> and others)
spectrum_cs.c 0.4.2 (Pavel Roskin <proski@gnu.org> and others)
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfd20) does not match type (0x0021)
hermes @ IO 0xf6000000: Truncating LTV record from 129544 to 8 bytes. (rid=0xfd20, len=0xfd05)
eth0: Station identity 0002:0001:4920:2000
eth0: Looks like a Lucent/Agere firmware version 18720.8192
eth0: Ad-hoc demo mode supported
eth0: IEEE standard IBSS ad-hoc mode supported
eth0: WEP supported, 104-bit key
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc01) does not match type (0x5e00)
hermes @ IO 0xf6000000: Truncating LTV record from 129030 to 6 bytes. (rid=0xfc01, len=0xfc04)
eth0: MAC address 14:1C:01:00:20:49
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc0e) does not match type (0x7200)
hermes @ IO 0xf6000000: Truncating LTV record from 129058 to 34 bytes. (rid=0xfc0e, len=0xfc12)
eth0: Station name "m I"
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfd10) does not match type (0x72ff)
hermes @ IO 0xf6000000: Truncating LTV record from 129538 to 2 bytes. (rid=0xfd10, len=0xfd02)
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc06) does not match type (0x72ff)
hermes @ IO 0xf6000000: Truncating LTV record from 129022 to 2 bytes. (rid=0xfc06, len=0xfc00)
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc83) does not match type (0x722b)
hermes @ IO 0xf6000000: Truncating LTV record from 129026 to 2 bytes. (rid=0xfc83, len=0xfc02)
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc25) does not match type (0x722b)
hermes @ IO 0xf6000000: Truncating LTV record from 129022 to 2 bytes. (rid=0xfc25, len=0xfc00)
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc0c) does not match type (0x7264)
hermes @ IO 0xf6000000: Truncating LTV record from 129026 to 2 bytes. (rid=0xfc0c, len=0xfc02)
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc0d) does not match type (0x7264)
hermes @ IO 0xf6000000: Truncating LTV record from 129026 to 2 bytes. (rid=0xfc0d, len=0xfc02)
eth0: ready
eth0: index 0x01: Vcc 3.3, irq 39, io 0xf6000000-0xf6000047
From everything I have seen here and elsewhere, it is apparently a bad orinoco module in the kernel.
Can you tell me exactly which one(s) you found that got you at least to the "ping" stage?
Thanks
[div align=\"right\"][a href=\"index.php?act=findpost&pid=92824\"][{POST_SNAPBACK}][/a][/div]
me too it locks-up when trying to access the network.
Did you get it work?
If it can help you:
When I do ifup wlan0, I get no device found.
When I do iwconfig, the hole thing freezes up.
Thanks
-
Well, first of all, those truncated LTV records are consistent with what I'm seeing. I can also run wellenreiter without problem, but lock up the moment I touch the opie network app or iwconfig
my MAC is also scrambled, but some of the octets are recognizable. But all of our addresses here SHOULD be starting with 00, and they're not. So something is definitely borken
Now let's have a look at this dmesg log, specifically the names of the RIDs that are failing
STAIdentity (I'm betting the firmware revision is NOT 18-thousand some odd number, just a hunch)
hermes @ IO 0xf6000000: Truncating LTV record from 129544 to 8 bytes. (rid=0xfd20, len=0xfd05)
eth0: Station identity 0002:0001:4920:2000
eth0: Looks like a Lucent/Agere firmware version 18720.8192
eth0: Ad-hoc demo mode supported
eth0: IEEE standard IBSS ad-hoc mode supported
eth0: WEP supported, 104-bit key
cnfOwnMACAddress (note this is where the MAC is failing)
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc01) does not match type (0x5e00)
hermes @ IO 0xf6000000: Truncating LTV record from 129030 to 6 bytes. (rid=0xfc01, len=0xfc04)
eth0: MAC address 14:1C:01:00:20:49
cnfOwnName (not really sure what this value should be, but chances are "m I" is going to end up being wrong. Quick google shows me this is probably trying to set "Prism I")
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc0e) does not match type (0x7200)
hermes @ IO 0xf6000000: Truncating LTV record from 129058 to 34 bytes. (rid=0xfc0e, len=0xfc12)
eth0: Station name "m I"
ChannelList
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfd10) does not match type (0x72ff)
hermes @ IO 0xf6000000: Truncating LTV record from 129538 to 2 bytes. (rid=0xfd10, len=0xfd02)
cnfSystemScale
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc06) does not match type (0x72ff)
hermes @ IO 0xf6000000: Truncating LTV record from 129022 to 2 bytes. (rid=0xfc06, len=0xfc00)
RTSThreshold
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc83) does not match type (0x722b)
hermes @ IO 0xf6000000: Truncating LTV record from 129026 to 2 bytes. (rid=0xfc83, len=0xfc02)
cnfDefaultKey1
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc25) does not match type (0x722b)
hermes @ IO 0xf6000000: Truncating LTV record from 129022 to 2 bytes. (rid=0xfc25, len=0xfc00)
cnfMaxSleepDuration
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc0c) does not match type (0x7264)
hermes @ IO 0xf6000000: Truncating LTV record from 129026 to 2 bytes. (rid=0xfc0c, len=0xfc02)
cnfPMHoldoverDuration
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc0d) does not match type (0x7264)
hermes @ IO 0xf6000000: Truncating LTV record from 129026 to 2 bytes. (rid=0xfc0d, len=0xfc02)
eth0: ready
eth0: index 0x01: Vcc 3.3, irq 39, io 0xf6000000-0xf6000047
I also doubt each of these messages is supposed to be in excess of 128k.
I'm no kernel debugger here, but let's take a look at the MAC address record, for one:
hermes @ IO 0xf6000000: Truncating LTV record from 129030 to 6 bytes.
That makes sense. A MAC address should be 6 bytes long, not 129030. So it appears that we are doing the correct thing by truncating these records, but what we need to find out is why these records are over one hundred thousand bytes long to begin with.
Now, it appears that hermes.c defines the hermes_read_ltv function, which is called by orinoco.c - so that PROBABLY means that orinoco.c is doing Something Wrong or is being passed bad data from spectrum_cs.
It might be worthwhile checking what paramaters we can pass to these modules at load time, but gut feeling here is that these modules will need to be recompiled.
EDIT:
Looking at the following:
The other weird part is the mis-interpretation of the MAC address, it is really:
MAC 00 A0 F8 5E 14 1C
instead of the
MAC address 14:1C:01:00:02:88 that is shows above
We see that it seems to be getting the last 2 bytes of the MAC correct, but setting them as the FIRST two bytes in software (the rest is probably junk data).
Also noticing that in the cnfOwnName record, it's getting the last three bytes ("m I") correct. Presumably, it's getting the last four, since the fourth would be a null terminator - which is why we probably don't see any junk data after the "I".
I'm not really sure what this tells us about the driver itself, but it's possible that memory addresses are being shifted/transposed here, which may also have something to do with the length of these LTV records being horribly, horribly WRONG (ie. the variable that stores the record length isn't pointing at record length data).
-
Any news on this issue guys?
getting the same error unable to handle kernel paging request at virtual address on same memory address.
-
Copied/Pasted from another topic about this (although that topic seems to be quite dead)
Well, first of all, those truncated LTV records are consistent with what I'm seeing. I can also run wellenreiter without problem, but lock up the moment I touch the opie network app or iwconfig
my MAC is also scrambled, but some of the octets are recognizable. But all of our addresses here SHOULD be starting with 00, and they're not. So something is definitely borken
Now let's have a look at this dmesg log, specifically the names of the RIDs that are failing
STAIdentity (I'm betting the firmware revision is NOT 18-thousand some odd number, just a hunch)
hermes @ IO 0xf6000000: Truncating LTV record from 129544 to 8 bytes. (rid=0xfd20, len=0xfd05)
eth0: Station identity 0002:0001:4920:2000
eth0: Looks like a Lucent/Agere firmware version 18720.8192
eth0: Ad-hoc demo mode supported
eth0: IEEE standard IBSS ad-hoc mode supported
eth0: WEP supported, 104-bit key
cnfOwnMACAddress (note this is where the MAC is failing)
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc01) does not match type (0x5e00)
hermes @ IO 0xf6000000: Truncating LTV record from 129030 to 6 bytes. (rid=0xfc01, len=0xfc04)
eth0: MAC address 14:1C:01:00:20:49
cnfOwnName (not really sure what this value should be, but chances are "m I" is going to end up being wrong. Quick google shows me this is probably trying to set "Prism I")
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc0e) does not match type (0x7200)
hermes @ IO 0xf6000000: Truncating LTV record from 129058 to 34 bytes. (rid=0xfc0e, len=0xfc12)
eth0: Station name "m I"
ChannelList
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfd10) does not match type (0x72ff)
hermes @ IO 0xf6000000: Truncating LTV record from 129538 to 2 bytes. (rid=0xfd10, len=0xfd02)
cnfSystemScale
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc06) does not match type (0x72ff)
hermes @ IO 0xf6000000: Truncating LTV record from 129022 to 2 bytes. (rid=0xfc06, len=0xfc00)
RTSThreshold
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc83) does not match type (0x722b)
hermes @ IO 0xf6000000: Truncating LTV record from 129026 to 2 bytes. (rid=0xfc83, len=0xfc02)
cnfDefaultKey1
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc25) does not match type (0x722b)
hermes @ IO 0xf6000000: Truncating LTV record from 129022 to 2 bytes. (rid=0xfc25, len=0xfc00)
cnfMaxSleepDuration
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc0c) does not match type (0x7264)
hermes @ IO 0xf6000000: Truncating LTV record from 129026 to 2 bytes. (rid=0xfc0c, len=0xfc02)
cnfPMHoldoverDuration
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc0d) does not match type (0x7264)
hermes @ IO 0xf6000000: Truncating LTV record from 129026 to 2 bytes. (rid=0xfc0d, len=0xfc02)
eth0: ready
eth0: index 0x01: Vcc 3.3, irq 39, io 0xf6000000-0xf6000047
I also doubt each of these messages is supposed to be in excess of 128k.
I'm no kernel debugger here, but let's take a look at the MAC address record, for one:
hermes @ IO 0xf6000000: Truncating LTV record from 129030 to 6 bytes.
That makes sense. A MAC address should be 6 bytes long, not 129030. So it appears that we are doing the correct thing by truncating these records, but what we need to find out is why these records are over one hundred thousand bytes long to begin with.
Now, it appears that hermes.c defines the hermes_read_ltv function, which is called by orinoco.c - so that PROBABLY means that orinoco.c is doing Something Wrong or is being passed bad data from spectrum_cs.
It might be worthwhile checking what paramaters we can pass to these modules at load time, but gut feeling here is that these modules will need to be recompiled.
EDIT:
Looking at the following:
The other weird part is the mis-interpretation of the MAC address, it is really:
MAC 00 A0 F8 5E 14 1C
instead of the
MAC address 14:1C:01:00:02:88 that is shows above
We see that it seems to be getting the last 2 bytes of the MAC correct, but setting them as the FIRST two bytes in software (the rest is probably junk data).
Also noticing that in the cnfOwnName record, it's getting the last three bytes ("m I") correct. Presumably, it's getting the last four, since the fourth would be a null terminator - which is why we probably don't see any junk data after the "I".
I'm not really sure what this tells us about the driver itself, but it's possible that memory addresses are being shifted/transposed here, which may also have something to do with the length of these LTV records being horribly, horribly WRONG (ie. the variable that stores the record length isn't pointing at record length data).
-
Copied/Pasted from another topic about this (although that topic seems to be quite dead)
Well, first of all, those truncated LTV records are consistent with what I'm seeing. I can also run wellenreiter without problem, but lock up the moment I touch the opie network app or iwconfig
my MAC is also scrambled, but some of the octets are recognizable. But all of our addresses here SHOULD be starting with 00, and they're not. So something is definitely borken
Now let's have a look at this dmesg log, specifically the names of the RIDs that are failing
STAIdentity (I'm betting the firmware revision is NOT 18-thousand some odd number, just a hunch)
hermes @ IO 0xf6000000: Truncating LTV record from 129544 to 8 bytes. (rid=0xfd20, len=0xfd05)
eth0: Station identity 0002:0001:4920:2000
eth0: Looks like a Lucent/Agere firmware version 18720.8192
eth0: Ad-hoc demo mode supported
eth0: IEEE standard IBSS ad-hoc mode supported
eth0: WEP supported, 104-bit key
cnfOwnMACAddress (note this is where the MAC is failing)
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc01) does not match type (0x5e00)
hermes @ IO 0xf6000000: Truncating LTV record from 129030 to 6 bytes. (rid=0xfc01, len=0xfc04)
eth0: MAC address 14:1C:01:00:20:49
cnfOwnName (not really sure what this value should be, but chances are "m I" is going to end up being wrong. Quick google shows me this is probably trying to set "Prism I")
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc0e) does not match type (0x7200)
hermes @ IO 0xf6000000: Truncating LTV record from 129058 to 34 bytes. (rid=0xfc0e, len=0xfc12)
eth0: Station name "m I"
ChannelList
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfd10) does not match type (0x72ff)
hermes @ IO 0xf6000000: Truncating LTV record from 129538 to 2 bytes. (rid=0xfd10, len=0xfd02)
cnfSystemScale
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc06) does not match type (0x72ff)
hermes @ IO 0xf6000000: Truncating LTV record from 129022 to 2 bytes. (rid=0xfc06, len=0xfc00)
RTSThreshold
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc83) does not match type (0x722b)
hermes @ IO 0xf6000000: Truncating LTV record from 129026 to 2 bytes. (rid=0xfc83, len=0xfc02)
cnfDefaultKey1
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc25) does not match type (0x722b)
hermes @ IO 0xf6000000: Truncating LTV record from 129022 to 2 bytes. (rid=0xfc25, len=0xfc00)
cnfMaxSleepDuration
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc0c) does not match type (0x7264)
hermes @ IO 0xf6000000: Truncating LTV record from 129026 to 2 bytes. (rid=0xfc0c, len=0xfc02)
cnfPMHoldoverDuration
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc0d) does not match type (0x7264)
hermes @ IO 0xf6000000: Truncating LTV record from 129026 to 2 bytes. (rid=0xfc0d, len=0xfc02)
eth0: ready
eth0: index 0x01: Vcc 3.3, irq 39, io 0xf6000000-0xf6000047
I also doubt each of these messages is supposed to be in excess of 128k.
I'm no kernel debugger here, but let's take a look at the MAC address record, for one:
hermes @ IO 0xf6000000: Truncating LTV record from 129030 to 6 bytes.
That makes sense. A MAC address should be 6 bytes long, not 129030. So it appears that we are doing the correct thing by truncating these records, but what we need to find out is why these records are over one hundred thousand bytes long to begin with.
Now, it appears that hermes.c defines the hermes_read_ltv function, which is called by orinoco.c - so that PROBABLY means that orinoco.c is doing Something Wrong or is being passed bad data from spectrum_cs.
It might be worthwhile checking what paramaters we can pass to these modules at load time, but gut feeling here is that these modules will need to be recompiled.
EDIT:
Looking at the following:
The other weird part is the mis-interpretation of the MAC address, it is really:
MAC 00 A0 F8 5E 14 1C
instead of the
MAC address 14:1C:01:00:02:88 that is shows above
We see that it seems to be getting the last 2 bytes of the MAC correct, but setting them as the FIRST two bytes in software (the rest is probably junk data).
Also noticing that in the cnfOwnName record, it's getting the last three bytes ("m I") correct. Presumably, it's getting the last four, since the fourth would be a null terminator - which is why we probably don't see any junk data after the "I".
I'm not really sure what this tells us about the driver itself, but it's possible that memory addresses are being shifted/transposed here, which may also have something to do with the length of these LTV records being horribly, horribly WRONG (ie. the variable that stores the record length isn't pointing at record length data).
[div align=\"right\"][a href=\"index.php?act=findpost&pid=96335\"][{POST_SNAPBACK}][/a][/div]
Ya, I saw this post but it all sounds greek to me loll.
-
Sorry guys for the late reply ... but I have been on an extended journey out of the lower 48 and needed my Zaurus to work - so I loaded Watapon which worked great on my Poodle (SL5600 and Socket WLAN).
I will check back in on OZ eventually when I get a bit of time.
-
Sorry guys for the late reply ... but I have been on an extended journey out of the lower 48 and needed my Zaurus to work - so I loaded Watapon which worked great on my Poodle (SL5600 and Socket WLAN).
I will check back in on OZ eventually when I get a bit of time.
Thanks vektortgecko, but that is the conclusion I was coming to - a byte pointer was somewhat off somewhere ...
-
Hi,
I'm having exactly the same problem with my 5600 + Opie 3.5.4-RC
Has anyone found a solution to this yet?
I've spent many hours searching for info & trying various solution (but only just found this topic..)
The card I have is a Symbol Spectrum24 Wireless networker, LA-4137-1020-WW
This appears to match the entry in spectrum.conf
card "LA4100 Spectrum24 CF WLAN Card"
manfid 0x026c, 0x0001
bind "spectrum_cs"
The one thing I have noticed is that the dmesg output we are seeing is rather different from a working setup with one of these cards (taken from the end of this post re. the Sharp rom by russilwvong: https://www.oesf.org/forums/index.php?showtopic=14812 (https://www.oesf.org/forums/index.php?showtopic=14812) )
Good:
hermes.c: 7 Jun 2002 David Gibson <hermes@gibson.dropbear.id.au>
orinoco.c 0.12 (David Gibson <hermes@gibson.dropbear.id.au> and others)
spectrum_cs.c 0.3.4
eth0: Station identity 0021:0002:0002:0001
eth0: Looks like a Symbol firmware version [F3.10-06] (parsing to 31006)
eth0: Ad-hoc demo mode supported
eth0: IEEE standard IBSS ad-hoc mode supported
eth0: WEP supported, 104-bit key
eth0: MAC address 00:A0:F8:A0:C3:56
eth0: Station name "Prism I"
eth0: ready
eth0: index 0x01: Vcc 3.3, irq 35, io 0xf6000000-0xf6000047
Bad (first few lines):
orinoco.c 0.13e (David Gibson <hermes@gibson.dropbear.id.au> and others)
spectrum_cs.c 0.4.2 (Pavel Roskin <proski@gnu.org> and others)
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfd20) does not match type (0x0021)
hermes @ IO 0xf6000000: Truncating LTV record from 129544 to 8 bytes. (rid=0xfd20, len=0xfd05)
eth0: Station identity 0002:0001:33fb:33cb
eth0: Looks like a Lucent/Agere firmware v
The driver modules load in a different sequence & the card is mis-identified as Lucent/Agere rather than Symbol..
Any clues here?
Robert Jenkins.
-
The 4137 (prism2.5 deriative) is _not_ compatible with the 4100 (prismII deriative) spectrum_cs driver. You _may_ have more luck with using hostap_cs + firmware upload. See the prism3-support package as well as the README contained inside.
-
I don't follow your reasoning..
If that's the case, how did russilwvong get exactly the same card as mine running with the same Orinoco driver, albeit a slightly older version?
I've been studying the Orinoco sources, I get the impression that it's a build problem or bug with the driver rather than a fundamental incompatibility.
(The Sharp 0.12 build works, the Opie 0.13e build does not.)
Note this line:
hermes_read_ltv(): rid (0xfd20) does not match type (0x0021)
The working example has Station identity 0021:0002:0002:0001
The 0021 is what identifies the card as a Symbol type to the driver.
The duff one is apparently reading the 0x0021, but when it's finished building the station identity block it's corrupt, probably offset by two words to give the 0002:0001:33fb:33cb
The driver then sees the initial 0002 in place of 0021 and goes haywire from that point, trying to handle it as an Agere device rather than Symbol.
More:
Working throught the hermes & orinoco code, it looks like the 0xfd20 is a command sent to the card to retrieve a specific data block.
This should return the block length, the original request code, then the data.
It's seeing the first word of the 'station identity' data in place of the block type code, then the remainder of the data is offset by two words.
It seems that somehow the buffering is getting out of step with the read data in the 'hermes' module.
This is during the basic, low-level, card init & ID stuff, before the driver tries to identify which specific card it's working with.
Could the be something to do with the structure alignment problem I've seen mentioned elsewhere?
Robert Jenkins.
-
And more:
It looks as if loading the card firmware is done during the PCMCIA 'card inserted' setup & this is working - the light on the card is flashing.
According to the Zaurus user group WiFi page, half the supported cards are Prism 2.5, including the Symbol & Socket cards.
http://www.zaurususergroup.org/modules.php...lessCardSupport (http://www.zaurususergroup.org/modules.php?op=modload&name=phpWiki&file=index&pagename=WirelessCardSupport)
The driver they specify for these is 'the Spectrum/Socket CF driver by Pavel Roskin'. The page this is on is dated 2002, not exactly a new development.
http://www.cypherpunks.ca/zaurus/socket.html (http://www.cypherpunks.ca/zaurus/socket.html)
(It's a different build of the package to the previous working one I'd seen from the Sharp site).
I don't want to go back to the Sharp rom, but it's starting to look like the only way of getting this Symbol card working in the near future
The reason I bought this in the first place was because of all the recommendations I'd seen for it... I assumed anything that worked with the rather old Sharp roms would have been covered in the OZ roms.
From some of the posts on the Orinoco mailing lists, it appears there could be a problem with builds for ARM against the more recent kernels, which does not seem to have been followed up?
Does anyone on here have the sources for the Orinoco drivers, as used on the 3.5.4Rc build & do you know a (working) link to the Sharp sources, or has anyone got a copy they have grabbed?
I'm aware of the Orinoco project & CVS, but I would like to compare the exact files used in the Z builds after any patching etc.
I'm setting up to do a full OE build from scratch so I can try & debug the drivers, but from what I have read so far that's probably going to take a very long time to get running sucessfully..
-
but from what I have read so far that's probably going to take a very long time to get running sucessfully..
No, it's quite easy actually (but I have been using it for a long while) - drop me a line if you need any help setting it up.
Si
-
Hi Si,
many thanks for the offer of assistance!
I've now got a machine set up with a clean install of Fedora core 4, plus all the required packages mentioned in the Open Embedded info & the ARM toolchain.
It looks like it should work, but I've not had time yet to try actually building anything.
One thing that bothers me with this setup, is how do you guarantee a consistent build? It appears to download and patch sources on the fly as it needs them, so each person building the 'same' (eg) OZ 3.5.4 package could actually end up with different binaries - is this correct??
Do the 'final' patched sources get saved, like into a local copy of the kernel source tree etc?
On the Symbol / Orinoco drivers again, I found this which I think is a definitive answer (from hostap mailing list archive):
-------------------
On Tue, 2005-05-17 at 13:51 -0500, Adam Roach wrote:
> I have a Symbol Spectrum24 High Rate LA4137 wireless lan card. I was
> wondering if this is what I need to be using to get it working.
No, this card has Symbol chipset, whereas HostAP requires Prism chipset.
You should use Orinoco driver instead.
--
Regards,
Pavel Roskin
--------------------
I've also found more references to other ROM builds for the Zaurus series in which the Orinoco package works with the Symbol LA4137 Card.
Note that my Symbol card is 'new' but with a manufacturing date of 2003 & driver CD dated 2001; it's hardly the latest Symbol hardware version.
I get the impression that the very latest Symbol cards do use a different chipset, possibly Hermes2 from some list posts, but the 4137 is covered by the Orinoco spectrum driver.
I still think the problem is in the OZ build or the particular Orinoco source version used in it, or the libraries / tool chain used with OZ.
The dmesg errors are very similar to the ones Michael Lauer reported in the Orinoco mailing list, as if there is a problem with the 'hermes' module accessing the card hardware?
Robert Jenkins.