Re: Request for information regarding BCM94311MCG rev 02

2007-11-21 Thread Johannes Berg

 Does this mean the DMA engines are implemented in silicon? 

Yeah, it's not implemented in the firmware so it must be in silicon.

 If so, there may be an error in the chip
 design. AFAIK, all Windows DMA is done to really low-order memory, and such a 
 defect would not show
 there. I do not know if this card is ever used on a Mac.

Hmm. This is of course possible but I doubt it a bit since the DMA
engine seems to be a quite highly-used piece of code.

  Between 2.6.24-rc2 and -rc3, code that resulted in the Descriptor Address
  Rings having low addresses was removed. At that point, my card failed with 
  a DMA error. When the
  ring buffer is forced to a low address by requesting it with the GFP_DMA 
  flag, then the card works.
  Note that the data buffers for DMA are still at high addresses - only the 
  ring buffer is low.
  
  Maybe the card can't handle high addresses for the buffers or we're
  doing something wrong with the address (extension) here?
 
 According to the specs, a flat 64-bit address is used for the ring buffer and 
 it should be OK to put
 the buffer anywhere in RAM. Only the data buffers require messing with an 
 extension field; however,
 my test machine has only 1.5 GB RAM, and all addresses fit in the low-order 
 32 bits.

Right. Or so we thought :)

 On a whim, I decided to look at the latest version of ndiswrapper, and
 found this code snippet:
 
 #ifdef CONFIG_X86_64
 /* 64-bit broadcom driver doesn't work if DMA is allocated
  * from over 1GB */
 if (wd-vendor == 0x14e4) {
 if (pci_set_dma_mask(pdev, DMA_30BIT_MASK) ||
 pci_set_consistent_dma_mask(pdev, DMA_30BIT_MASK))
 WARNING(couldn't set DMA mask; this driver 
 may not work with more than 1GB
 RAM);
 }
 #endif
 
 This makes it look more-and-more like a design problem with the
 hardware.

But this isn't quite correct either is it?

You said before that we should be fine allocating the DMA rings below
1GB and then doing arbitrary DMA buffers. If this is the case, then imho
we should just do that, the six DMA rings or whatever we should be able
to fit into low memory.

johannes


signature.asc
Description: This is a digitally signed message part
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Request for information regarding BCM94311MCG rev 02

2007-11-21 Thread Larry Finger
Johannes Berg wrote:
 It appears that I have found either a hardware error with my copy of that 
 card, or there is an error
 in the ucode13 firmware. 
 
 FWIW, the firmware is hardly involved in DMA so that's extremely
 unlikely.

Does this mean the DMA engines are implemented in silicon? If so, there may be 
an error in the chip
design. AFAIK, all Windows DMA is done to really low-order memory, and such a 
defect would not show
there. I do not know if this card is ever used on a Mac.

 Between 2.6.24-rc2 and -rc3, code that resulted in the Descriptor Address
 Rings having low addresses was removed. At that point, my card failed with a 
 DMA error. When the
 ring buffer is forced to a low address by requesting it with the GFP_DMA 
 flag, then the card works.
 Note that the data buffers for DMA are still at high addresses - only the 
 ring buffer is low.
 
 Maybe the card can't handle high addresses for the buffers or we're
 doing something wrong with the address (extension) here?

According to the specs, a flat 64-bit address is used for the ring buffer and 
it should be OK to put
the buffer anywhere in RAM. Only the data buffers require messing with an 
extension field; however,
my test machine has only 1.5 GB RAM, and all addresses fit in the low-order 32 
bits.

Larry

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Request for information regarding BCM94311MCG rev 02

2007-11-20 Thread Larry Finger
Is anyone running my 4311 rev 02 patches? If so, I need some help.

It appears that I have found either a hardware error with my copy of that card, 
or there is an error
in the ucode13 firmware. Between 2.6.24-rc2 and -rc3, code that resulted in the 
Descriptor Address
Rings having low addresses was removed. At that point, my card failed with a 
DMA error. When the
ring buffer is forced to a low address by requesting it with the GFP_DMA flag, 
then the card works.
Note that the data buffers for DMA are still at high addresses - only the ring 
buffer is low.

If you are using my patch, the card is working,  and 'uname -r' results in 
2.6.24-rc3, please let me
know. If you kernel version is 2.6.24-rc2 or earlier, please apply the attached 
patch and report
your findings.

Thanks,

Larry
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index da69d83..12376ae 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -749,23 +749,6 @@ int move_freepages_block(struct zone *zone, struct page 
*page, int migratetype)
return move_freepages(zone, start_page, end_page, migratetype);
 }
 
-/* Return the page with the lowest PFN in the list */
-static struct page *min_page(struct list_head *list)
-{
-   unsigned long min_pfn = -1UL;
-   struct page *min_page = NULL, *page;;
-
-   list_for_each_entry(page, list, lru) {
-   unsigned long pfn = page_to_pfn(page);
-   if (pfn  min_pfn) {
-   min_pfn = pfn;
-   min_page = page;
-   }
-   }
-
-   return min_page;
-}
-
 /* Remove an element from the buddy allocator from the fallback list */
 static struct page *__rmqueue_fallback(struct zone *zone, int order,
int start_migratetype)
@@ -789,11 +772,8 @@ static struct page *__rmqueue_fallback(struct zone *zone, 
int order,
if (list_empty(area-free_list[migratetype]))
continue;
 
-   /* Bias kernel allocations towards low pfns */
page = list_entry(area-free_list[migratetype].next,
struct page, lru);
-   if (unlikely(start_migratetype != MIGRATE_MOVABLE))
-   page = min_page(area-free_list[migratetype]);
area-nr_free--;
 
/*
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Request for information

2007-11-11 Thread evan foss
Sorry I meant to send this to the list.

On Nov 10, 2007 6:12 PM, evan foss [EMAIL PROTECTED] wrote:
 I am not sure if this is correct as I still don't have the b43 driver
 working but here is my boxes data.

 013063133C100800BE0D00FF11430080021000181400B7A5155442303D15A0FA79FEFF834AFF3EFF494A02FF53550CFF020A

 The box is a compaq v3019us the chip is a bcm4311. For some reason the
 lspci reads this instead of what it read under 2.6.20-r6.

 01:00.0 Network controller: Broadcom Corporation BCM94311MCG wlan
 mini-PCI (rev 01)
 Subsystem: Hewlett-Packard Company Unknown device 1363
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
 Stepping- SERR+ FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-
 TAbort- MAbort- SERR- PERR- INTx-
 Latency: 0, Cache Line Size: 64 bytes
 Interrupt: pin A routed to IRQ 19
 Region 0: Memory at c300 (32-bit, non-prefetchable) [size=16K]
 Capabilities: [40] Power Management version 2
 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA 
 PME(D0-,D1-,D2-,D3hot-,D3cold-)
 Status: D0 PME-Enable- DSel=0 DScale=2 PME-
 Capabilities: [58] Message Signalled Interrupts: Mask- 64bit- 
 Queue=0/0 Enable-
 Address:   Data: 
 Capabilities: [d0] Express (v1) Legacy Endpoint, MSI 00
 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 4us, 
 L1 unlimited
 ExtTag+ AttnBtn- AttnInd- PwrInd- RBE- FLReset-
 DevCtl: Report errors: Correctable- Non-Fatal- Fatal- 
 Unsupported-
 RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
 MaxPayload 128 bytes, MaxReadReq 128 bytes
 DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- 
 TransPend-
 LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency 
 L0 4us, L1 64us
 ClockPM- Suprise- LLActRep- BwNot-
 LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- 
 CommClk-
 ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
 LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ 
 DLActive-
 BWMgmt- ABWMgmt-
 Capabilities: [100] Advanced Error Reporting
 Capabilities: [13c] Virtual Channel

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




-- 
http://www.coe.neu.edu/~efoss/
http://evanfoss.googlepages.com/
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Request for information

2007-11-11 Thread Ehud Gavron

Based on your problem description...
there isn't one.

Based on your uname -a ...
there isn't one.

Based on your dmesg...
there isn't one.

This is like a locked room mystery, right, you want us to solve the 
problem without the problem being

a. mentioned
b. described
c. error messages mentioned
or even
d. the environment described.

Wow, you have a lot of faith.

Ehud
PS Good thing you have two whole web pages!  Perhaps that way you can be 
famous in your genius.


evan foss wrote:

Sorry I meant to send this to the list.

On Nov 10, 2007 6:12 PM, evan foss [EMAIL PROTECTED] wrote:
  

I am not sure if this is correct as I still don't have the b43 driver
working but here is my boxes data.

013063133C100800BE0D00FF11430080021000181400B7A5155442303D15A0FA79FEFF834AFF3EFF494A02FF53550CFF020A

The box is a compaq v3019us the chip is a bcm4311. For some reason the
lspci reads this instead of what it read under 2.6.20-r6.

01:00.0 Network controller: Broadcom Corporation BCM94311MCG wlan
mini-PCI (rev 01)
Subsystem: Hewlett-Packard Company Unknown device 1363
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-
TAbort- MAbort- SERR- PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 19
Region 0: Memory at c300 (32-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
Capabilities: [58] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 
Enable-
Address:   Data: 
Capabilities: [d0] Express (v1) Legacy Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 4us, L1 
unlimited
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE- FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- 
Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- 
TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 
4us, L1 64us
ClockPM- Suprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ 
DLActive-
BWMgmt- ABWMgmt-
Capabilities: [100] Advanced Error Reporting
Capabilities: [13c] Virtual Channel

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






  


smime.p7s
Description: S/MIME Cryptographic Signature
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev