Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 2 subscribers
  • Views 704 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

WLAN-AP mit ASL 4.003

ehudler
Hi everybody !!
It's me again; still having troubles getting the WLAN-AP up and running. I've the kernel-logs from the boot sequenze (WLAN-station & WLAN-AP) attached - any hints ?????

+++++++++++++++++++ WLAN - Station  +++++++++++++++++++++++++++

: klogd 1.3-3, log source = /proc/kmsg started.
: Cannot open map file: /System.map.
: Loaded 98 symbols from 3 modules.
: Intel(R) PRO/100 Network Driver - version 2.1.29
: Copyright (c) 2002 Intel Corporation
: 
: PCI: Found IRQ 10 for device 00:03.0
: PCI: Sharing IRQ 10 with 00:02.2
: e100: selftest OK.
: e100: eth0: Intel(R) 8255x-based Ethernet Adapter
: 
: rtl8139.c:v1.20 6/21/2002 Donald Becker, becker@scyld.com.
:  http://www.scyld.com/network/rtl8139.html
: eth1: RealTek RTL8139C Fast Ethernet at 0x7800, IRQ 9, 00:48:54[:D]1:a7:57.
: usb.c: registered new driver usbdevfs
: usb.c: registered new driver hub
: usb.c: registered new driver hiddev
: usb.c: registered new driver hid
: hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik 
: hid-core.c: USB HID support drivers
: ip_tables: (C) 2000-2002 Netfilter core team
: ip_conntrack version 2.1 (8192 buckets, 65536 max) - 320 bytes per conntrack
: Linux PCMCIA Card Services 3.2.1
:   kernel build: 2.4.19-C2_23 #2 Wed Jan 22 10:29:32 CET 2003
:   options:  [pci] [cardbus]
: Intel ISA/PCI/CardBus PCIC probe:
: PCI: Enabling device 00:10.0 (0000 -> 0002)
: PCI: Assigned IRQ 5 for device 00:10.0
:   Ricoh RL5C475 rev 80 PCI-to-CardBus at slot 00:10, mem 0xf3eff000
:     host opts [0]: [pci only] [io 3/6/1] [mem 3/6/1] [pci irq 5] [lat 168/176] [bus 2/5]
:     PCI card interrupts, PCI status changes
: cs: memory probe 0xa0000000-0xa0ffffff: clean.
: init_module: prism2_cs.o: 0.1.15 Loaded
: init_module: dev_info is: prism2_cs
: cs: IO port probe 0x0100-0x04ff: excluding 0x220-0x22f 0x388-0x38f 0x3b8-0x3df 0x4d0-0x4d7
: cs: IO port probe 0x0230-0x0387: clean.
: cs: IO port probe 0x0390-0x03b7: clean.
: cs: IO port probe 0x03e0-0x04cf: clean.
: cs: IO port probe 0x04d8-0x04ff: clean.
: cs: IO port probe 0x0800-0x08ff: clean.
: cs: IO port probe 0x0c00-0x0cff: clean.
: prism2_cs: index 0x01: Vcc 3.3, irq 5, io 0x0100-0x013f
: ident: nic h/w: id=0x800c 1.0.0
: ident: pri f/w: id=0x15 1.0.7
: ident: sta f/w: id=0x1f 1.3.5
: MFI:SUP:role=0x00:id=0x01:var=0x01:b/t=1/1
: CFI:SUP:role=0x00:id=0x02:var=0x02:b/t=1/1
: PRI:SUP:role=0x00:id=0x03:var=0x01:b/t=4/4
: STA:SUP:role=0x00:id=0x04:var=0x01:b/t=1/9
: PRI-CFI:ACT:role=0x01:id=0x02:var=0x02:b/t=1/1
: STA-CFI:ACT:role=0x01:id=0x02:var=0x02:b/t=1/1
: STA-MFI:ACT:role=0x01:id=0x01:var=0x01:b/t=1/1
: Prism2 card SN: 99SA01000000
: dot11req_reset: the macaddress and setdefaultmib arguments are currently unsupported.
: e100: eth0 NIC Link is Up 100 Mbps Full duplex
: netfilter PSD loaded - (c) astaro AG
: ident: nic h/w: id=0x800c 1.0.0
: ident: pri f/w: id=0x15 1.0.7
: ident: sta f/w: id=0x1f 1.3.5
: MFI:SUP:role=0x00:id=0x01:var=0x01:b/t=1/1
: CFI:SUP:role=0x00:id=0x02:var=0x02:b/t=1/1
: PRI:SUP:role=0x00:id=0x03:var=0x01:b/t=4/4
: STA:SUP:role=0x00:id=0x04:var=0x01:b/t=1/9
: PRI-CFI:ACT:role=0x01:id=0x02:var=0x02:b/t=1/1
: STA-CFI:ACT:role=0x01:id=0x02:var=0x02:b/t=1/1
: STA-MFI:ACT:role=0x01:id=0x01:var=0x01:b/t=1/1
: Prism2 card SN: 99SA01000000

+++++++++++++++++++++ up & running   ++++++++++++++++++++++

to be continued %  


This thread was automatically locked due to age.
Parents
  • 0
    That's about it - stuck in the middle of nowhere !!!
    Anyone an idea what I could do next ?? - For me, the problem is in the "prism2dl" process - seems to load the PDA & the hex-file not correctly.

    Could somebody tell me if there is a connection with the following articel:

        Subject: [PATCH] Flash download works!!!
    From: Pavel Roskin  gnu.org>
    Date: Sun, 13 Apr 2003 20:04:04 -0400 (EDT)
    Newsgroups: gmane.linux.drivers.hostap

    Hello!

    The problem with flash download appears to lie in the userspace.  When
    dumping the actual data written to the card, I have found that the data is
    different from the data written by prism2dl.  It was shifted by 4 bytes.

    It turned out that the wrong data comes from the prism2_srec.  Function
    combine_info() moves data in the wrong direction when it prepends the
    checksum.

    The patch is attached.  After applying the patch, my download code worked
    right away, and I was able to upgrade secondary firmware on SMC2632W from
    0.7.6 to 1.4.9.

    The patch for firmware download is also attached, but it needs some work.
    The card cannot be reset after download, so prism2_srec reports an error.
    It's sufficient to eject and insert the card to see the new firmware.
    Also, maxtimeout needs to be used in hfa384x_cmd_wait(), and it should be
    done in a more graceful way.  At least this patch doesn't kill the card.

    Testing shows that RAM download is not affected.  RAM download for primary
    firmware still doesn't work.  Secondary firmware is still OK.

    If we want to update primary firmware in the flash, prism2_srec should be
    able to process primary and secondary firmware in one operation.  Flashing
    only primary firmware makes the card unusable.  This was tested both with
    prism2dl and prism2_srec.

    -- 
    Regards,
    Pavel Roskin
      
Reply
  • 0
    That's about it - stuck in the middle of nowhere !!!
    Anyone an idea what I could do next ?? - For me, the problem is in the "prism2dl" process - seems to load the PDA & the hex-file not correctly.

    Could somebody tell me if there is a connection with the following articel:

        Subject: [PATCH] Flash download works!!!
    From: Pavel Roskin  gnu.org>
    Date: Sun, 13 Apr 2003 20:04:04 -0400 (EDT)
    Newsgroups: gmane.linux.drivers.hostap

    Hello!

    The problem with flash download appears to lie in the userspace.  When
    dumping the actual data written to the card, I have found that the data is
    different from the data written by prism2dl.  It was shifted by 4 bytes.

    It turned out that the wrong data comes from the prism2_srec.  Function
    combine_info() moves data in the wrong direction when it prepends the
    checksum.

    The patch is attached.  After applying the patch, my download code worked
    right away, and I was able to upgrade secondary firmware on SMC2632W from
    0.7.6 to 1.4.9.

    The patch for firmware download is also attached, but it needs some work.
    The card cannot be reset after download, so prism2_srec reports an error.
    It's sufficient to eject and insert the card to see the new firmware.
    Also, maxtimeout needs to be used in hfa384x_cmd_wait(), and it should be
    done in a more graceful way.  At least this patch doesn't kill the card.

    Testing shows that RAM download is not affected.  RAM download for primary
    firmware still doesn't work.  Secondary firmware is still OK.

    If we want to update primary firmware in the flash, prism2_srec should be
    able to process primary and secondary firmware in one operation.  Flashing
    only primary firmware makes the card unusable.  This was tested both with
    prism2dl and prism2_srec.

    -- 
    Regards,
    Pavel Roskin
      
Children
No Data
Cookie Information Banner