lkml.org 
[lkml]   [2004]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Linux Incompatibility List
From
Date
On Sat, 2004-08-28 at 21:42 -0400, Andrew Miklas wrote:
> (Sorry for the long delay...)

Thats OK.

> Yeah, we tried that at first too (actually, we were using Frank Cornelis'
> patches to Bochs). The problem with dumping all the PCI activity (even while
> the interface isn't sending/receiving) is that there is a huge amount of data
> to sift through. Even capturing for just a for a few seconds generates
> megabytes of data. You also have to deal with various events (like the
> watchdog timer) going off at random times and getting mixed in with the
> send/receive data. We also found DMA a little tricky too (ie. you need to
> dump out any data that the chip will bus-master to itself to see how it is
> structured).

OK, exactly which drivers were you using to do this? When I had the
interface brought up in win2k-server with the bcmwl5.sys driver I was
seeing every few hundred milliseconds a batch of say 12 2-byte reads on
the register space to check status...

> Also, we figured it would cause problems for supporting the whole range of
> devices that can be handled by the wl.o drivers. For example, from looking
> at the module, we can see that the driver will have somewhat different
> behaviour according to exactly what MAC and radio chips are present, the
> interface being used (ie. PCI, cardbus, etc.), the vendor, model number, and
> revision of the board itself, the contents of the ROM, etc. We decided that
> there was simply too many combinations to make the data capture approach
> useful over the entire range of Broadcom hardware, unless you repeat the
> process on every variation.

Hrm, you're sure those variations aren't trivial? Although theres lots
of checks, I would have thought they would just be stuff like "card A
supports X, Y and Z features"?

The approach that makes the most sense to me is get 1 card working to
the point where it sends/receives packets, then look at the binaries to
see what the variations are, and how they apply to what cards and just
go fill in the blanks...

> > Anyway, perhaps once I've had some time to make a little more progress
> > we would be able to compare some notes?
>
> Sure, let me know when you're ready.

I just need to improve logging support in my pciproxy patch and setup a
2nd machine with a working wireless card, then I can start in earnest.

Also, you mention DMA and sending/receiving packets, exactly how much
progress have you made so far?

--
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-03-22 14:05    [W:0.085 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site