Maybe a subtle kernel/module mismatch? 

Forum: PCMCIA on Toshiba laptops
Re: Question: BreezeCom/Raylink PCMCIA Does Not Configure on Toshiba Tecra (John Turkovich)
Date: 1999, Dec 10
From: David Hinds <dhinds@pcmcia.sourceforge.org>

I'm not exactly sure how this came to pass, but my best guess is that you've got a kernel that was configured with "maximum physical memory" set to 2GB... and most of your PCMCIA modules know this and are fine, however, the ray_cs.o module thinks this is set to 1GB. Did you compile the ray_cs module yourself? Did you compile either your own kernel, or your own PCMCIA package? If I had to guess, I'd say that you are using a stock kernel and PCMCIA package (which work together fine), but you got a pre-compiled ray_cs.o file from another source? -- Dave

[ Next-in-Thread ]  [ Next Message ] 

Messages Inline: [ 0 ]  [ All ]  Outline: [ 1 ]  [ 2 ]  [ All ] 

Question: Configures but Cannot Contact Re: Maybe a subtle kernel/module mismatch? (David Hinds) Date: 1999, Dec 17 From: John Turkovich <turkovich@draper.com>

Dave, Thanks for your help. I hope that you can assist me further. My host recognizes and configures the BreezeCom card. However, I still can't reach my Access Point. Statements numbered 1.0-6.0 below outline my situation. The remaining text in each section provides details about my situation. JJT 1.0 I corrected the maximum physical memory specifications mismatch. You are correct about the way I specified max physical memory! The Linux kernel was made with a Maximum Physical Memory of 2GB. When I was recompiling ray_cs.c, using the prescribed make config and make all in a temporary directory, the default Maximum Physical Memory was 1GB. I was copying ray_cs.0 from the temporary directory to my working directory, /lib/modules/2.2.13-7mdk/pcmcia. Now I'm using 2GB for Maximum Physical Memory in both places. When I insert the BreezeCom (RayLink) card it both recognizes and configures. (I get two high tone beeps.) When I remove the card I get one high tone beep and my system remains stable. 2.0 I can ping the PCMCIA card's IP address 140.102.82.74 See: [root@maryland modules]# /bin/ping 140.102.82.74 PING 140.102.82.74 (140.102.82.74): 56 data bytes 64 bytes from 140.102.82.74: icmp_seq=0 ttl=255 time=0.4 ms 64 bytes from 140.102.82.74: icmp_seq=1 ttl=255 time=0.3 ms 64 bytes from 140.102.82.74: icmp_seq=2 ttl=255 time=0.3 ms 64 bytes from 140.102.82.74: icmp_seq=3 ttl=255 time=0.3 ms --- 140.102.82.74 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 0.3/0.3/0.4 ms 3.0 However, I cannot ping another machnine on my network. See: [root@maryland modules]# /bin/ping 140.102.82.35 PING 140.102.82.35 (140.102.82.35): 56 data bytes --- 140.102.82.35 ping statistics --- 4 packets transmitted, 0 packets received, 100% packet loss 4.0 I know that my wireless network on the Access Point side of the network is operational because I can ping 140.102.82.35 from a Windows 98 platform that contains a BreezeCom card. 5.0 The following are pertinent messages from /var/log/messages: ================= Inserting BreezeCom (RayLink) PCMCIA card =================== Dec 13 15:32:08 maryland cardmgr[338]: initializing socket 1 Dec 13 15:32:09 maryland cardmgr[338]: socket 1: RayLink PC Card WLAN Adapter Dec 13 15:32:09 maryland cardmgr[338]: executing: 'insmod /lib/modules/2.2.13-7mdk/pcmcia/ray_cs.o bc=1 pc_debug=4 essid=ESSID1 hop_dwell=128 beacon_period=256 translate=1 net_type=1' Dec 13 15:32:09 maryland kernel: $Id: ray_cs.c,v 1.67 1999/10/24 15:12:12 corey Exp $ - Corey Thomas corey@world.std.com Dec 13 15:32:09 maryland kernel: raylink init_module register_pcmcia_driver returns 0x0 Dec 13 15:32:09 maryland kernel: ray_attach() Dec 13 15:32:09 maryland kernel: ray_attach link = 81ceeea0, dev = 81ceec60, local = 8033f000, intr = 8284b92c Dec 13 15:32:09 maryland kernel: ray_cs ray_attach calling ether_setup.) Dec 13 15:32:09 maryland kernel: ray_cs ray_attach calling CardServices(RegisterClient...) Dec 13 15:32:09 maryland kernel: ray_event(0x000004) Dec 13 15:32:09 maryland kernel: ray_config entered. Dec 13 15:32:09 maryland kernel: ray_config(0x81ceeea0) Dec 13 15:32:09 maryland kernel: ray_cs Detected: RAYTHEON RayLink PC Card WLAN Adapter Version 4.82 Dec 97 Dec 13 15:32:09 maryland kernel: sram=800d1000 Set up 32k window for shared memory (transmit and control completed. Dec 13 15:32:09 maryland kernel: rmem=800d9000 Set up 16k window for shared memory (receive buffer) completed. Dec 13 15:32:09 maryland kernel: amem=800dd000 Set up window for attribute memory completed. Dec 13 15:32:09 maryland kernel: ray_config sram=800d1000 Dec 13 15:32:09 maryland kernel: ray_config rmem=800d9000 Dec 13 15:32:09 maryland kernel: ray_config amem=800dd000 Dec 13 15:32:09 maryland cardmgr[338]: executing: './network start eth0' Dec 13 15:32:09 maryland kernel: ray_init(0x81ceec60) Dec 13 15:32:09 maryland kernel: ray_init firmware version 85.85 Dec 13 15:32:09 maryland kernel: ray_init tib_length = 0x20 Dec 13 15:32:09 maryland kernel: ray_init ending Dec 13 15:32:09 maryland kernel: ray_dev_init(dev=81ceec60) Dec 13 15:32:09 maryland kernel: dl_startup_params entered Dec 13 15:32:09 maryland kernel: dl_startup_params start ccsindex = 14 Dec 13 15:32:09 maryland kernel: interrupt_ecf(local=8033f000, ccs = 0xe Dec 13 15:32:09 maryland kernel: ray_cs dl_startup_params started timer for verify_dl_startup Dec 13 15:32:09 maryland kernel: ray_dev_init ending Dec 13 15:32:09 maryland kernel: eth0: RayLink, irq 3, hw_addr 00:00:8F:88:F1:81 Dec 13 15:32:09 maryland kernel: Returning from ray_config. Dec 13 15:32:09 maryland kernel: ray_cs ray_attach ending Dec 13 15:32:09 maryland kernel: ray_open('eth0') Dec 13 15:32:09 maryland kernel: ray_open ending Dec 13 15:32:09 maryland kernel: ray_cs set_multicast_list(81ceec60) Dec 13 15:32:09 maryland kernel: ray_cs set_multicast_list(81ceec60) Dec 13 15:32:09 maryland cardmgr[338]: + route: netmask doesn't match route address Dec 13 15:32:09 maryland cardmgr[338]: + Usage: route [-nNvee] [-FC] [<AF>] List kernel routing tables Dec 13 15:32:09 maryland cardmgr[338]: + route [-v] [-FC] {add|del|flush} ... Modify routing table for AF. Dec 13 15:32:09 maryland cardmgr[338]: + Dec 13 15:32:09 maryland cardmgr[338]: + route {-h|--help} [<AF>] Detailed usage syntax for specified AF. Dec 13 15:32:09 maryland cardmgr[338]: + route {-V|--version} Display version/author and exit. Dec 13 15:32:09 maryland cardmgr[338]: + Dec 13 15:32:09 maryland cardmgr[338]: + -v, --verbose be verbose Dec 13 15:32:09 maryland cardmgr[338]: + -n, --numeric dont resolve names Dec 13 15:32:09 maryland cardmgr[338]: + -N, --symbolic resolve hardware names Dec 13 15:32:09 maryland cardmgr[338]: + -e, --extend display other/more information Dec 13 15:32:09 maryland kernel: ray_update_multi_list(81ceec60) Dec 13 15:32:09 maryland kernel: ray_update_multi add addr 01005e000001 Dec 13 15:32:09 maryland kernel: ray_cs update_multi 1 addresses in list Dec 13 15:32:09 maryland kernel: interrupt_ecf(local=8033f000, ccs = 0xe Dec 13 15:32:09 maryland kernel: ray_cs set_multicast_list(81ceec60) Dec 13 15:32:09 maryland kernel: ray_cs set_multicast_list(81ceec60) Dec 13 15:32:09 maryland kernel: 1 0 5e 0 0 1 44 31 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 8f 88 f1 81 7f ff 2 0 0 1 1 7 50 3f 82 ce 7f ff fb 1e c7 5c 5 4 2 4 0 c bd 4e ff ff 5 ff 1 b 4e 3f f 4 8 28 28 7 0 2 2 aa aa 3 0 0 0 1 4f 55 55 55 55 55 Dec 13 15:32:09 maryland kernel: interrupt_ecf(local=8033f000, ccs = 0xe Dec 13 15:32:09 maryland cardmgr[338]: + -F, --fib display Forwarding Information Base (default) Dec 13 15:32:09 maryland cardmgr[338]: + -C, --cache display routing cache instead of FIB Dec 13 15:32:09 maryland cardmgr[338]: + Dec 13 15:32:09 maryland cardmgr[338]: + <AF>=Use '-A <af>' or '--<af>' Default: inet Dec 13 15:32:09 maryland cardmgr[338]: + List of possible address families (which support routing): Dec 13 15:32:09 maryland cardmgr[338]: + inet (DARPA Internet) ax25 (AMPR AX.25) netrom (AMPR NET/ROM) Dec 13 15:32:09 maryland cardmgr[338]: + ipx (Novell IPX) ddp (Appletalk DDP) Dec 13 15:32:11 maryland kernel: ray_cs interrupt network "ESSID1" joined Dec 13 15:32:11 maryland kernel: ray_cs Starting authentication. Dec 13 15:32:11 maryland kernel: interrupt_ecf(local=8033f000, ccs = 0x0 Dec 13 15:32:11 maryland kernel: ray_cs interrupt tx request complete Dec 13 15:32:11 maryland kernel: Authentication refused Dec 13 15:32:11 maryland kernel: interrupt_ecf(local=8033f000, ccs = 0xe Dec 13 15:32:15 maryland kernel: ray_cs interrupt network "ESSID1" join failed Dec 13 15:32:20 maryland kernel: interrupt_ecf(local=8033f000, ccs = 0xe Dec 13 15:32:21 maryland kernel: ray_cs interrupt network "ESSID1" joined Dec 13 15:32:21 maryland kernel: ray_cs Starting authentication. Dec 13 15:32:21 maryland kernel: interrupt_ecf(local=8033f000, ccs = 0x0 Dec 13 15:32:21 maryland kernel: ray_cs interrupt tx request complete Dec 13 15:32:21 maryland kernel: Authentication successful Dec 13 15:32:21 maryland kernel: ray_cs Starting association with access point Dec 13 15:32:21 maryland kernel: interrupt_ecf(local=8033f000, ccs = 0xe Dec 13 15:32:22 maryland kernel: ray_cs association successful Dec 13 15:32:22 maryland kernel: ray_cs untranslate NOT SNAP ffffff Dec 13 15:32:22 maryland kernel: untranslate after skb_pull(10), skb->data = 8062249c Dec 13 15:32:23 maryland kernel: ray_cs untranslate NOT SNAP ffffff Dec 13 15:32:23 maryland kernel: untranslate after skb_pull(10), skb->data = 806222bc Dec 13 15:32:23 maryland kernel: ray_cs untranslate NOT SNAP ffffff Dec 13 15:32:23 maryland kernel: untranslate after skb_pull(10), skb->data = 8062249c Dec 13 15:32:23 maryland kernel: ray_cs untranslate NOT SNAP ffffff Dec 13 15:32:23 maryland kernel: untranslate after skb_pull(10), skb->data = 806222bc Dec 13 15:32:23 maryland kernel: ray_cs untranslate NOT SNAP ffffff Dec 13 15:32:23 maryland kernel: untranslate after skb_pull(10), skb->data = 81ceeb5c Dec 13 15:32:23 maryland kernel: ray_cs untranslate NOT SNAP ffffff Dec 13 15:32:23 maryland kernel: untranslate after skb_pull(10), skb->data = 81ceeb5c Dec 13 15:32:24 maryland kernel: ray_cs untranslate NOT SNAP ffffff Dec 13 15:32:24 maryland kernel: untranslate after skb_pull(10), skb->data = 8062249c Dec 13 15:32:24 maryland kernel: ray_cs untranslate NOT SNAP ffffff Dec 13 15:32:24 maryland kernel: untranslate after skb_pull(10), skb->data = 806222bc Dec 13 15:32:24 maryland kernel: ray_cs untranslate NOT SNAP ffffff Dec 13 15:32:24 maryland kernel: untranslate after skb_pull(10), skb->data = 81ceeb5c Dec 13 15:32:25 maryland kernel: ray_cs untranslate NOT SNAP ffffff Dec 13 15:32:25 maryland kernel: untranslate after skb_pull(10), skb->data = 806222bc Dec 13 15:32:25 maryland kernel: ray_cs untranslate NOT SNAP ffffff Dec 13 15:32:25 maryland kernel: untranslate after skb_pull(10), skb->data = 8062235c Dec 13 15:32:25 maryland kernel: ray_cs untranslate NOT SNAP ffffff Dec 13 15:32:25 maryland kernel: untranslate after skb_pull(10), skb->data = 8062253c Dec 13 15:32:25 maryland kernel: ray_cs untranslate NOT SNAP ffffff Dec 13 15:32:25 maryland kernel: untranslate after skb_pull(10), skb->data = 806223fc Dec 13 15:32:25 maryland kernel: ray_cs untranslate NOT SNAP ffffff Dec 13 15:32:25 maryland kernel: untranslate after skb_pull(10), skb->data = 81ceeb5c Dec 13 15:32:26 maryland kernel: ray_cs untranslate NOT SNAP ffffff Dec 13 15:32:26 maryland kernel: untranslate after skb_pull(10), skb->data = 806223fc Dec 13 15:32:26 maryland kernel: ray_cs untranslate NOT SNAP ffffff Dec 13 15:32:26 maryland kernel: untranslate after skb_pull(10), skb->data = 8062253c Dec 13 15:32:26 maryland kernel: ray_cs untranslate NOT SNAP ffffff Dec 13 15:32:26 maryland kernel: untranslate after skb_pull(10), skb->data = 81ceeb5c Dec 13 15:32:26 maryland kernel: ray_cs untranslate NOT SNAP ffffff Dec 13 15:32:26 maryland kernel: untranslate after skb_pull(10), skb->data = 8062253c Dec 13 15:32:26 maryland kernel: ray_cs untranslate NOT SNAP ffffff Dec 13 15:32:26 maryland kernel: untranslate after skb_pull(10), skb->data = 806223fc Dec 13 15:32:26 maryland kernel: ray_cs untranslate NOT SNAP ffffff Dec 13 15:32:26 maryland kernel: untranslate after skb_pull(10), skb->data = 8062253c 6.0 Yet another kind of periodic message ==== The above debug message keeps repeating. ==== ==== Periodically the following happens ==== ==== and then the above untranslate message starts ==== repeating ==== Dec 13 15:33:00 maryland kernel: ray_dev_start_xmit(skb=80c7bb40, dev=81ceec60) Dec 13 15:33:00 maryland kernel: ray_hw_xmit(data=8107eb42, len=60, dev=81ceec60) Dec 13 15:33:00 maryland kernel: ray_cs translate_frame DIX II Dec 13 15:33:00 maryland kernel: ray_hw_xmit default_tx_rate = 0x3 Dec 13 15:33:00 maryland kernel: interrupt_ecf(local=8033f000, ccs = 0x0 Dec 13 15:33:00 maryland kernel: ray_cs interrupt tx request complete Dec 13 15:33:00 maryland kernel: ray_cs untranslate RFC default Dec 13 15:33:00 maryland kernel: untranslate after skb_pull(18), skb->data = 8107eb64 Dec 13 15:33:00 maryland kernel: ray_cs untranslate NOT SNAP ffffff Dec 13 15:33:00 maryland kernel: untranslate after skb_pull(10), skb->data = 81cee5bc Dec 13 15:33:00 maryland kernel: ray_cs untranslate NOT SNAP ffffff Dec 13 15:33:00 maryland kernel: untranslate after skb_pull(10), skb->data = 81b98ebc Dec 13 15:33:00 maryland kernel: ray_cs untranslate NOT SNAP ffffff Dec 13 15:33:00 maryland kernel: untranslate after skb_pull(10), skb->data = 81cee5bc Dec 13 15:33:01 maryland kernel: ray_cs untranslate NOT SNAP ffffff Dec 13 15:33:01 maryland kernel: untranslate after skb_pull(10), skb->data = 81b98ebc Dec 13 15:33:01 maryland kernel: ray_dev_start_xmit(skb=80c7b540, dev=81ceec60) Dec 13 15:33:01 maryland kernel: ray_hw_xmit(data=8107eb42, len=60, dev=81ceec60) Dec 13 15:33:01 maryland kernel: ray_cs translate_frame DIX II Dec 13 15:33:01 maryland kernel: ray_hw_xmit default_tx_rate = 0x3 Dec 13 15:33:01 maryland kernel: interrupt_ecf(local=8033f000, ccs = 0x0 Dec 13 15:33:01 maryland kernel: ray_cs interrupt tx request complete Dec 13 15:33:01 maryland kernel: ray_cs untranslate RFC default Dec 13 15:33:01 maryland kernel: untranslate after skb_pull(18), skb->data = 8107eb64 Dec 13 15:33:01 maryland kernel: ray_cs untranslate NOT SNAP ffffff Dec 13 15:33:01 maryland kernel: untranslate after skb_pull(10), skb->data = 81cee5bc Dec 13 15:33:01 maryland kernel: ray_cs untranslate NOT SNAP ffffff Dec 13 15:33:01 maryland kernel: untranslate after skb_pull(10), skb->data = 8062253c

1. You'll probably need to talk to the ray_cs guy by David Hinds, 1999, Dec 17

[ Add Message ]  to: "Maybe a subtle kernel/module mismatch?"

[ Members ]  [ Subscribe ]  [ Admin Mode ] 
[ Show Frames ]  [ Help for HyperNews at pcmcia-cs.sourceforge.net 1.10 ]