Re: [PATCH V2] bcm43xx: Fix failure to deliver PCI-E interrupts

2007-01-18 Thread evan foss

One thing I forgot is that the LED will be on only if the switch is in the on 
position _AND_ the
interface is UP.


Yes I figured that out. (eventually)


 dhcpcd eth1   -low transmit power???
 Most likely. How far are you from the AP?

 This is a timeout issue. I tried to apply the timeout patch which I
 assume is for this and it didn't take. I have logs for both patch
 applications below. To the distance issue my ap died so I am trying to
 just connect to one next door. (with permission) The distance is about
 50ft. So this could be the main factor. This is why I said it might be
 my fault. The thing is I can connect to it in windows most of the time
 so I know it is in range. I will be going to school on Tuesday and
 will report back then. They have a much better AP.

With the current transmit levels of the 4311, 50 feet through at least one wall 
is probably too much.


I have tried 3 more AP at much closer distances 9ft and 4ft and it
still won't work. I ether get Network Down or a timeout.



 Presario1600 bcm43xx # patch -p0 patch_2.6.18.1_signal_quality

...

 Presario1600 bcm43xx # patch -p0 patch_2.6.18.1_watchdog_timeout2

...

Those patches are already applied to your code.


Thanks for the clarification, and assistance.

--
http://www.coe.neu.edu/~efoss/
http://evanfoss.googlepages.com/
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V2] bcm43xx: Fix failure to deliver PCI-E interrupts

2007-01-14 Thread evan foss

I sent this to the list but I don't know if it got to the list.

On 1/14/07, evan foss [EMAIL PROTECTED] wrote:

Results so far
In a word Wow. It still doesn't work but I suspect that is could just
be my configuration. Power levels are not being reported correctly all
the time iwlist works but nothing else to my knowledge. I remember
there being talk of power level reporting patches. Is there anything I
can try adding. For the first time in a long time it does associate
with AP's but I can't dhcpcd eth1. I am using an access point next
door. Mine is down. I will test it with a good one at school on
Tuesday.

To recap I am on...
MFG: Compaq V3000 (V3019US)
CPU: AMD Turion 64 x2
Kernel: linux-2.6.18-gentoo-r2
I have SMP on and I am in 64 bit.
BCM Chip: BCM4311
BCM FW: V3 Sorry I don't recall exactly what version

Patches used
patch_2.6.18.1_fix_leds
patch_2.6.18.1_for_PCI-E
radio_hwenable_for_2.6.18

The following work
ifconfig eth1 up
iwconfig eth1 essid NAME channel #
kismet -c bcm43xx,eth1,bcm43xx
iwlist eth1 scan-the power levels are reported here

The following don't work
iwconfig-the power levels are reported as always being 0
kismet  -no power levels are reported
LED -always off (I have a slider switch on the front to 
turn radio on/off)
dhcpcd eth1 -low transmit power???

#The following don't work but might be my fault (I will get back
to you later on these)
dhcpcd eth1

#example bad iwconfig power level reporting
eth1  IEEE 802.11b/g  ESSID:linksys  Nickname:Broadcom 4311
  Mode:Managed  Frequency=2.437 GHz  Access Point: 00:16:B6:43:DE:C4
  Bit Rate=1 Mb/s   Tx-Power=18 dBm
  RTS thr:off   Fragment thr:off
  Encryption key:off
  Link Quality=0/100  Signal level=-256 dBm  Noise level=-256 dBm
  Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
  Tx excessive retries:0  Invalid misc:0   Missed beacon:0



--
http://www.coe.neu.edu/~efoss/
http://evanfoss.googlepages.com/




--
http://www.coe.neu.edu/~efoss/
http://evanfoss.googlepages.com/
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V2] bcm43xx: Fix failure to deliver PCI-E interrupts

2007-01-14 Thread Larry Finger
evan foss wrote:
 Results so far
 In a word Wow. It still doesn't work but I suspect that is could just
 be my configuration. Power levels are not being reported correctly all
 the time iwlist works but nothing else to my knowledge. I remember
 there being talk of power level reporting patches. Is there anything I
 can try adding. For the first time in a long time it does associate
 with AP's but I can't dhcpcd eth1. I am using an access point next
 door. Mine is down. I will test it with a good one at school on
 Tuesday.
 
 To recap I am on...
 MFG: Compaq V3000 (V3019US)
 CPU: AMD Turion 64 x2
 Kernel: linux-2.6.18-gentoo-r2
   I have SMP on and I am in 64 bit.
 BCM Chip: BCM4311
 BCM FW: V3 Sorry I don't recall exactly what version
 
 Patches used
 patch_2.6.18.1_fix_leds
 patch_2.6.18.1_for_PCI-E
 radio_hwenable_for_2.6.18

To get signal levels reported correctly, you also need 
patch_2.6.18.1_signal_quality.

 The following work
 ifconfig eth1 up
 iwconfig eth1 essid NAME channel #
 kismet -c bcm43xx,eth1,bcm43xx
 iwlist eth1 scan  -the power levels are reported here
 
 The following don't work
 iwconfig  -the power levels are reported as always being 0
 kismet-no power levels are reported
 LED   -always off (I have a slider switch on the front to 
 turn radio on/off)

This one needs watching. The LED has worked on previous computers.

 dhcpcd eth1   -low transmit power???

Most likely. How far are you from the AP?

 #The following don't work but might be my fault (I will get back
 to you later on these)
 dhcpcd eth1
 
 #example bad iwconfig power level reporting
 eth1  IEEE 802.11b/g  ESSID:linksys  Nickname:Broadcom 4311
   Mode:Managed  Frequency=2.437 GHz  Access Point: 00:16:B6:43:DE:C4
   Bit Rate=1 Mb/s   Tx-Power=18 dBm
   RTS thr:off   Fragment thr:off
   Encryption key:off
   Link Quality=0/100  Signal level=-256 dBm  Noise level=-256 dBm
   Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
   Tx excessive retries:0  Invalid misc:0   Missed beacon:0

The received signal and noise levels should be fixed by the patch listed above.

Larry

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V2] bcm43xx: Fix failure to deliver PCI-E interrupts

2007-01-13 Thread evan foss

Results so far
In a word Wow. It still doesn't work but I suspect that is could just
be my configuration. Power levels are not being reported correctly all
the time iwlist works but nothing else to my knowledge. I remember
there being talk of power level reporting patches. Is there anything I
can try adding. For the first time in a long time it does associate
with AP's but I can't dhcpcd eth1. I am using an access point next
door. Mine is down. I will test it with a good one at school on
Tuesday.

To recap I am on...
MFG: Compaq V3000 (V3019US)
CPU: AMD Turion 64 x2
Kernel: linux-2.6.18-gentoo-r2
I have SMP on and I am in 64 bit.
BCM Chip: BCM4311
BCM FW: V3 Sorry I don't recall exactly what version

Patches used
patch_2.6.18.1_fix_leds
patch_2.6.18.1_for_PCI-E
radio_hwenable_for_2.6.18

The following work
ifconfig eth1 up
iwconfig eth1 essid NAME channel #
kismet -c bcm43xx,eth1,bcm43xx
iwlist eth1 scan-the power levels are reported here

The following don't work
iwconfig-the power levels are reported as always being 0
kismet  -no power levels are reported
LED -always off (I have a slider switch on the front to 
turn radio on/off)
dhcpcd eth1 -low transmit power???

#The following don't work but might be my fault (I will get back
to you later on these)
dhcpcd eth1

#example bad iwconfig power level reporting
eth1  IEEE 802.11b/g  ESSID:linksys  Nickname:Broadcom 4311
 Mode:Managed  Frequency=2.437 GHz  Access Point: 00:16:B6:43:DE:C4
 Bit Rate=1 Mb/s   Tx-Power=18 dBm
 RTS thr:off   Fragment thr:off
 Encryption key:off
 Link Quality=0/100  Signal level=-256 dBm  Noise level=-256 dBm
 Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
 Tx excessive retries:0  Invalid misc:0   Missed beacon:0



--
http://www.coe.neu.edu/~efoss/
http://evanfoss.googlepages.com/
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V2] bcm43xx: Fix failure to deliver PCI-E interrupts

2007-01-12 Thread Stephen Sinclair

The PCI-E modifications to bcm43xx do not set up the interrupt vector
correctly. Tested with BCM4311 (PCI-E) on x86_64 and BCM4306 (PCI) on i386.


This was successful for me.  My 4311 is now getting interrupts, and I
was able to successfully associate with an AP.  (i386)


Steve
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V2] bcm43xx: Fix failure to deliver PCI-E interrupts

2007-01-12 Thread Michael Buesch
On Friday 12 January 2007 19:08, Larry Finger wrote:
 The PCI-E modifications to bcm43xx do not set up the interrupt vector
 correctly. Tested with BCM4311 (PCI-E) on x86_64 and BCM4306 (PCI) on i386.
 
 Signed-off-by: Larry Finger [EMAIL PROTECTED]

ACK.

 ---
 
 John,
 
 This fix should be applied to wireless-2.6 _AND_ pushed upstream to
 2.6.20-rcX. Without this patch, none of the PCI-E interfaces will work.
 This version incorporates Michael Buesch's comments, and forgoes some
 code clean-ups that were in the first version/
 
 Larry
 
 
 Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
 ===
 --- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
 +++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
 @@ -2704,8 +2704,8 @@ static int bcm43xx_probe_cores(struct bc
   sb_id_hi = bcm43xx_read32(bcm, BCM43xx_CIR_SB_ID_HI);
  
   /* extract core_id, core_rev, core_vendor */
 - core_id = (sb_id_hi  0xFFF0)  4;
 - core_rev = (sb_id_hi  0xF);
 + core_id = (sb_id_hi  0x8FF0)  4;
 + core_rev = ((sb_id_hi  0xF) | ((sb_id_hi  0x7000)  8));
   core_vendor = (sb_id_hi  0x)  16;
  
   dprintk(KERN_INFO PFX Core %d: ID 0x%x, rev 0x%x, vendor 
 0x%x\n,
 @@ -2876,7 +2876,10 @@ static int bcm43xx_wireless_core_init(st
   sbimconfiglow = bcm43xx_read32(bcm, BCM43xx_CIR_SBIMCONFIGLOW);
   sbimconfiglow = ~ BCM43xx_SBIMCONFIGLOW_REQUEST_TOUT_MASK;
   sbimconfiglow = ~ BCM43xx_SBIMCONFIGLOW_SERVICE_TOUT_MASK;
 - sbimconfiglow |= 0x32;
 + if (bcm-bustype == BCM43xx_BUSTYPE_PCI)
 + sbimconfiglow |= 0x32;
 + else
 + sbimconfiglow |= 0x53;

This hunk is OK, but I just want to point out that bustype is
always equal to BCM43xx_BUSTYPE_PCI ;)
The 0x53 timeouts are for an SSB-BUS.
So strictly said this hunk is a NOP.

The other hunks are OK, too. They fix real bugs.
Thanks for spotting them, Larry!

   bcm43xx_write32(bcm, BCM43xx_CIR_SBIMCONFIGLOW, sbimconfiglow);
   }
  
 @@ -3080,7 +3083,7 @@ static int bcm43xx_setup_backplane_pci_c
   if (err)
   goto out;
  
 - if (bcm-current_core-rev  6 ||
 + if (bcm-current_core-rev  6 
   bcm-current_core-id == BCM43xx_COREID_PCI) {
   value = bcm43xx_read32(bcm, BCM43xx_CIR_SBINTVEC);
   value |= (1  backplane_flag_nr);
 
 ---
 
 

-- 
Greetings Michael.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V2] bcm43xx: Fix failure to deliver PCI-E interrupts

2007-01-12 Thread Michael Buesch
On Friday 12 January 2007 19:50, Stephen Sinclair wrote:
  The PCI-E modifications to bcm43xx do not set up the interrupt vector
  correctly. Tested with BCM4311 (PCI-E) on x86_64 and BCM4306 (PCI) on i386.
 
 This was successful for me.  My 4311 is now getting interrupts, and I
 was able to successfully associate with an AP.  (i386)

That does the (i386) mean here?
Were you able to accociate with your PCI or PCI-E card?

-- 
Greetings Michael.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V2] bcm43xx: Fix failure to deliver PCI-E interrupts

2007-01-12 Thread evan foss

This hunk is OK, but I just want to point out that bustype is
always equal to BCM43xx_BUSTYPE_PCI ;)
The 0x53 timeouts are for an SSB-BUS.
So strictly said this hunk is a NOP.

The other hunks are OK, too. They fix real bugs.
Thanks for spotting them, Larry!


So then what fixed int's for Stephen Sinclair? Or did they already
work? I would gladly help test I knew it applied to me.


The PCI-E modifications to bcm43xx do not set up the interrupt vector
correctly. Tested with BCM4311 (PCI-E) on x86_64 and BCM4306 (PCI) on i386.


This was successful for me.  My 4311 is now getting interrupts, and I
was able to successfully associate with an AP.  (i386)



--
http://www.coe.neu.edu/~efoss/
http://evanfoss.googlepages.com/
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V2] bcm43xx: Fix failure to deliver PCI-E interrupts

2007-01-12 Thread Larry Finger
Michael Buesch wrote:
 On Friday 12 January 2007 19:50, Stephen Sinclair wrote:
 The PCI-E modifications to bcm43xx do not set up the interrupt vector
 correctly. Tested with BCM4311 (PCI-E) on x86_64 and BCM4306 (PCI) on i386.
 This was successful for me.  My 4311 is now getting interrupts, and I
 was able to successfully associate with an AP.  (i386)
 
 That does the (i386) mean here?
 Were you able to accociate with your PCI or PCI-E card?

Stephen has an i386 system with a PCI-E 4311. The PCI card on i386 was mine, 
which I tested to make
sure the logic change didn't break the old systems. The display on my old 
laptop died and wasn't
worth fixing; however, I ssh into it to test on a PCI system.

Larry


-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V2] bcm43xx: Fix failure to deliver PCI-E interrupts

2007-01-12 Thread Larry Finger
evan foss wrote:
 This hunk is OK, but I just want to point out that bustype is
 always equal to BCM43xx_BUSTYPE_PCI ;)
 The 0x53 timeouts are for an SSB-BUS.
 So strictly said this hunk is a NOP.

 The other hunks are OK, too. They fix real bugs.
 Thanks for spotting them, Larry!
 
 So then what fixed int's for Stephen Sinclair? Or did they already
 work? I would gladly help test I knew it applied to me.

The lack of int's was due to the bugs mentioned above. His interface didn't 
work until he applied
the patch, which I hope fixes everyone's PCI-E problems. Please do test.

Larry

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V2] bcm43xx: Fix failure to deliver PCI-E interrupts

2007-01-12 Thread evan foss

You can get the 2.6.18 patches from

ftp://lwfinger.dynalias.org/patches. You will need the PCI-E

patch for 2.6.18.1, and will probably want the

patch_2.6.18.1_fix_leds and radio_hwenable_for_2.6.18

patches if your radio has a switch.


Thank you I will try it when I get the time.

--
http://www.coe.neu.edu/~efoss/
http://evanfoss.googlepages.com/
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html