Re: b43 kills my kernel
On 11/18/2009 08:54 AM, Peter Stuge wrote:
Oncaphillis wrote:
So as far as I understand both the early kernel as well as lspci
think that the mmio area of the Broadcom chip is located at
5710 only ssb gets the wrong address. It gets set in ssbioremap
via pci_iomap.
After the call to pci_iomap, the physical address (5710) gets
mapped into a virtual address within the process address space.
So it's fine.
Thanks for clarification. Based on the assumption that the IO mapping
is correct I had a closer look at sprom_do_read:
snip
int i;
for (i = 0; i bus-sprom_size; i++) {
printk(KERN_DEBUG In sprom_do_read idx:%d\n,i);
sprom[i] = ioread16(bus-mmio + SSB_SPROM_BASE + (i * 2));
}
/snip
The first ioread16 actually succeeds, only the second one fails.
My lspci -vnn tells me that the memory is:
Memory at 5710 (64-bit, non-prefetchable) [size=16K]
Could it be that one has to make a ioread32 here since the
memory is 64-bit ? I remember very very remotely that
in older days it was impossible or even forbidden to read
data from addresses which are not a multiple of 2/4/8 what
so ever. But that was pre-PCI.
Sebastian
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
On Wed, Nov 18, 2009 at 6:15 PM, Larry Finger larry.fin...@lwfinger.net wrote:
On 11/18/2009 08:34 AM, Oncaphillis wrote:
The first ioread16 actually succeeds, only the second one fails.
My lspci -vnn tells me that the memory is:
Memory at 5710 (64-bit, non-prefetchable) [size=16K]
Could it be that one has to make a ioread32 here since the
memory is 64-bit ? I remember very very remotely that
in older days it was impossible or even forbidden to read
data from addresses which are not a multiple of 2/4/8 what
so ever. But that was pre-PCI.
As long as a 16-bit read is aligned on an even address, it should be OK;
however, to check completely, please try this patch:
Index: wireless-testing/drivers/ssb/pci.c
===
--- wireless-testing.orig/drivers/ssb/pci.c
+++ wireless-testing/drivers/ssb/pci.c
@@ -251,10 +251,16 @@ static int sprom_check_crc(const u16 *sp
static int sprom_do_read(struct ssb_bus *bus, u16 *sprom)
{
int i;
+ u32 buf;
- for (i = 0; i bus-sprom_size; i++)
- sprom[i] = ioread16(bus-mmio + SSB_SPROM_BASE + (i * 2));
-
+ printk(KERN_INFO ssb: Entering %s\n, __func__);
+ for (i = 0; i bus-sprom_size; i = i + 2) {
I know this is just a debugging patch, but we use i+=2 or i += 2
in such cases.
+ buf = ioread32(bus-mmio + SSB_SPROM_BASE + (i * 2));
+ printk(KERN_INFO ssb: Read 0x%.8X from SPROM\n, buf);
+ sprom[i] = buf 0x;
+ sprom[i+1] = (buf 16) 0x;
+ }
+ printk(KERN_INFO ssb: Leaving %s\n, __func__);
return 0;
}
Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
On 11/18/2009 06:15 PM, Larry Finger wrote:
On 11/18/2009 08:34 AM, Oncaphillis wrote:
The first ioread16 actually succeeds, only the second one fails.
My lspci -vnn tells me that the memory is:
Memory at 5710 (64-bit, non-prefetchable) [size=16K]
Could it be that one has to make a ioread32 here since the
memory is 64-bit ? I remember very very remotely that
in older days it was impossible or even forbidden to read
data from addresses which are not a multiple of 2/4/8 what
so ever. But that was pre-PCI.
As long as a 16-bit read is aligned on an even address, it should be OK;
however, to check completely, please try this patch:
Index: wireless-testing/drivers/ssb/pci.c
===
--- wireless-testing.orig/drivers/ssb/pci.c
+++ wireless-testing/drivers/ssb/pci.c
@@ -251,10 +251,16 @@ static int sprom_check_crc(const u16 *sp
static int sprom_do_read(struct ssb_bus *bus, u16 *sprom)
{
int i;
+ u32 buf;
- for (i = 0; i bus-sprom_size; i++)
- sprom[i] = ioread16(bus-mmio + SSB_SPROM_BASE + (i * 2));
-
+ printk(KERN_INFO ssb: Entering %s\n, __func__);
+ for (i = 0; i bus-sprom_size; i = i + 2) {
+ buf = ioread32(bus-mmio + SSB_SPROM_BASE + (i * 2));
+ printk(KERN_INFO ssb: Read 0x%.8X from SPROM\n, buf);
+ sprom[i] = buf 0x;
+ sprom[i+1] = (buf 16) 0x;
+ }
+ printk(KERN_INFO ssb: Leaving %s\n, __func__);
return 0;
}
I already tried something similar. Unfortunately I can not report in detail
right now since I've once again killed my kernel and my acer stands at
home.
I'll give more details in a couple of hours -- but the punch line is:
(1) if I transform the series of ioread16 into a series of ioread32
the loop
runs through giving me a CRC error afterwards.
(2) I tried to compensate for different endianess by doing this:
u32 *my_buff = (u32 *)spromm;
u32 dw;
for (i = 0; i bus-sprom_size/2; i = i++) {
dw = ioread32(bus-mmio + SSB_SPROM_BASE + (i * 4));
my_buff[i] = (dw 16) | (dw 16);
}
Is there something fishy in that approach ? I'm really not a
hardware hacker. Still get a CRC error.
(3) My next approach was to do a initial ioread16 on the index 0. And
do the given loop afterwards including an output of read double words.
But it seems under these conditions the ioread32 fails too, since I
can't reach my laptop anymore.
Sebastian
Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
On Wednesday 18 November 2009 18:36:12 Oncaphillis wrote:
Index: wireless-testing/drivers/ssb/pci.c
===
--- wireless-testing.orig/drivers/ssb/pci.c
+++ wireless-testing/drivers/ssb/pci.c
@@ -251,10 +251,16 @@ static int sprom_check_crc(const u16 *sp
static int sprom_do_read(struct ssb_bus *bus, u16 *sprom)
{
int i;
+ u32 buf;
- for (i = 0; i bus-sprom_size; i++)
- sprom[i] = ioread16(bus-mmio + SSB_SPROM_BASE + (i * 2));
-
+ printk(KERN_INFO ssb: Entering %s\n, __func__);
+ for (i = 0; i bus-sprom_size; i = i + 2) {
+ buf = ioread32(bus-mmio + SSB_SPROM_BASE + (i * 2));
+ printk(KERN_INFO ssb: Read 0x%.8X from SPROM\n, buf);
+ sprom[i] = buf 0x;
+ sprom[i+1] = (buf 16) 0x;
+ }
+ printk(KERN_INFO ssb: Leaving %s\n, __func__);
return 0;
}
u32 *my_buff = (u32 *)spromm;
u32 dw;
for (i = 0; i bus-sprom_size/2; i = i++) {
dw = ioread32(bus-mmio + SSB_SPROM_BASE + (i * 4));
my_buff[i] = (dw 16) | (dw 16);
}
Is there something fishy in that approach ?
Yeah, completely wrong.
Use larry's patch.
I don't see why a 16bit access would hang. This code's been like this forever
and is tested on thousands of devices. We need to find out what's special about
your device. First being: Does your device actually _have_ an sprom? Or is
it some of these freaky built-in stripped-down save-two-cents devices?
So can you check what the first 16bit read returns? Just printk it.
If it returns all-ones, there's a good chance that there is no sprom at all.
--
Greetings, Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
On 11/18/2009 11:36 AM, Oncaphillis wrote:
I already tried something similar. Unfortunately I can not report in detail
right now since I've once again killed my kernel and my acer stands at
home.
I'll give more details in a couple of hours -- but the punch line is:
(1) if I transform the series of ioread16 into a series of ioread32 the
loop
runs through giving me a CRC error afterwards.
For you Rev. 8 SPROM, the program will get one CRC error as it first tries for
the smaller SPROM found in versions 1-3.
(2) I tried to compensate for different endianess by doing this:
Endianess is not an issue as you are just ding an internal transfer with le =
le or be = be.
u32 *my_buff = (u32 *)spromm;
u32 dw;
for (i = 0; i bus-sprom_size/2; i = i++) {
dw = ioread32(bus-mmio + SSB_SPROM_BASE + (i * 4));
my_buff[i] = (dw 16) | (dw 16);
}
This one certainly would fail.
After you get access to the machine, please try my patch. It has been tested
here. The first few lines from the output are:
ssb: Entering sprom_do_read
ssb: Read 0x2801 from SPROM
ssb: Read 0x103C137C from SPROM
ssb: Read 0x6DBE0078 from SPROM
Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: Enforce DMA descriptor memory constraints
Enforce all device constraints on the descriptor memory region.
There are several constraints on the descriptor memory, as documented
in the specification. The current code does not enforce them and/or
incorrectly enforces them.
Those constraints are:
- The address limitations on 30/32bit engines, that also apply to
the skbs.
- The 4k alignment requirement on 30/32bit engines.
- The 8k alignment requirement on 64bit engines.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
It's not entirely clear if any 64bit devices exist that _really_ need the 8k
alignment. However, I think it does not hurt much if we enforce it anyway.
The patch removes the always-set-GFP_DMA-on-64bit-devices hack. The combination
of
the new enforcements should be enough to keep every device happy, including
those
which needed the GFP_DMA hack. The new code will dynamically check if GFP_DMA is
required, instead of statically doing it all the time.
John, please queue for the next feature release. This patch still needs a fair
amount of testing. I think the best way to get it is to simply apply it. If this
causes any regressions, we can (temporary) revert it.
This also is a candidate for a b43legacy backport.
Index: wireless-testing/drivers/net/wireless/b43/dma.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/dma.c2009-11-18
19:09:38.0 +0100
+++ wireless-testing/drivers/net/wireless/b43/dma.c 2009-11-18
19:21:17.0 +0100
@@ -383,44 +383,160 @@ static inline
}
}
+/* Check if a DMA region fits the device constraints.
+ * Returns true, if the region is OK for usage with this device. */
+static inline bool b43_dma_address_ok(struct b43_dmaring *ring,
+ dma_addr_t addr, size_t size)
+{
+ switch (ring-type) {
+ case B43_DMA_30BIT:
+ if ((u64)addr + size (1ULL 30))
+ return 0;
+ break;
+ case B43_DMA_32BIT:
+ if ((u64)addr + size (1ULL 32))
+ return 0;
+ break;
+ case B43_DMA_64BIT:
+ /* Currently we can't have addresses beyond
+* 64bit in the kernel. */
+ break;
+ }
+ return 1;
+}
+
+#define is_4k_aligned(addr)(((u64)(addr) 0x0FFFull) == 0)
+#define is_8k_aligned(addr)(((u64)(addr) 0x1FFFull) == 0)
+
+static void b43_unmap_and_free_ringmem(struct b43_dmaring *ring, void *base,
+ dma_addr_t dmaaddr, size_t size)
+{
+ ssb_dma_unmap_single(ring-dev-dev, dmaaddr, size, DMA_TO_DEVICE);
+ free_pages((unsigned long)base, get_order(size));
+}
+
+static void * __b43_get_and_map_ringmem(struct b43_dmaring *ring,
+ dma_addr_t *dmaaddr, size_t size,
+ gfp_t gfp_flags)
+{
+ void *base;
+
+ base = (void *)__get_free_pages(gfp_flags, get_order(size));
+ if (!base)
+ return NULL;
+ memset(base, 0, size);
+ *dmaaddr = ssb_dma_map_single(ring-dev-dev, base, size,
+ DMA_TO_DEVICE);
+ if (ssb_dma_mapping_error(ring-dev-dev, *dmaaddr)) {
+ free_pages((unsigned long)base, get_order(size));
+ return NULL;
+ }
+
+ return base;
+}
+
+static void * b43_get_and_map_ringmem(struct b43_dmaring *ring,
+ dma_addr_t *dmaaddr, size_t size)
+{
+ void *base;
+
+ base = __b43_get_and_map_ringmem(ring, dmaaddr, size,
+GFP_KERNEL);
+ if (!base) {
+ b43err(ring-dev-wl, Failed to allocate or map pages
+ for DMA ringmemory\n);
+ return NULL;
+ }
+ if (!b43_dma_address_ok(ring, *dmaaddr, size)) {
+ /* The memory does not fit our device constraints.
+* Retry with GFP_DMA set to get lower memory. */
+ b43_unmap_and_free_ringmem(ring, base, *dmaaddr, size);
+ base = __b43_get_and_map_ringmem(ring, dmaaddr, size,
+GFP_KERNEL | GFP_DMA);
+ if (!base) {
+ b43err(ring-dev-wl, Failed to allocate or map pages
+ in the GFP_DMA region for DMA ringmemory\n);
+ return NULL;
+ }
+ if (!b43_dma_address_ok(ring, *dmaaddr, size)) {
+ b43_unmap_and_free_ringmem(ring, base, *dmaaddr, size);
+ b43err(ring-dev-wl, Failed to allocate DMA
+ ringmemory that fits device constraints\n);
+ return NULL;
+ }
+ }
+ /* We expect the memory to be 4k aligned, at least. */
+ if (B43_WARN_ON(!is_4k_aligned(*dmaaddr))) {
+
Re: [PATCH] b43: Enforce DMA descriptor memory constraints
On 11/18/2009 01:53 PM, Michael Buesch wrote: Enforce all device constraints on the descriptor memory region. There are several constraints on the descriptor memory, as documented in the specification. The current code does not enforce them and/or incorrectly enforces them. Those constraints are: - The address limitations on 30/32bit engines, that also apply to the skbs. - The 4k alignment requirement on 30/32bit engines. - The 8k alignment requirement on 64bit engines. Signed-off-by: Michael Buesch m...@bu3sch.de --- It's not entirely clear if any 64bit devices exist that _really_ need the 8k alignment. However, I think it does not hurt much if we enforce it anyway. The patch removes the always-set-GFP_DMA-on-64bit-devices hack. The combination of the new enforcements should be enough to keep every device happy, including those which needed the GFP_DMA hack. The new code will dynamically check if GFP_DMA is required, instead of statically doing it all the time. John, please queue for the next feature release. This patch still needs a fair amount of testing. I think the best way to get it is to simply apply it. If this causes any regressions, we can (temporary) revert it. This also is a candidate for a b43legacy backport. Tested OK for BCM4312 (14e4:4315). I will port/test on b43legacy as I have the hardware. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
On 11/18/2009 06:51 PM, Larry Finger wrote: After you get access to the machine, please try my patch. It has been tested here. The first few lines from the output are: ssb: Entering sprom_do_read ssb: Read 0x2801 from SPROM ssb: Read 0x103C137C from SPROM ssb: Read 0x6DBE0078 from SPROM It seems Michaels theory about a missing sprom is correct. It gives me: [ 10.551127] ssb: Found rev 1 PMU (capabilities 0x02A62F01) [ 10.551143] ssb: Entering sprom_do_read [ 10.551152] ssb: Read 0x from SPROM [ 10.551159] ssb: Read 0x from SPROM ... an so on Sebastian ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
On Wednesday 18 November 2009 23:07:29 Oncaphillis wrote: On 11/18/2009 06:51 PM, Larry Finger wrote: After you get access to the machine, please try my patch. It has been tested here. The first few lines from the output are: ssb: Entering sprom_do_read ssb: Read 0x2801 from SPROM ssb: Read 0x103C137C from SPROM ssb: Read 0x6DBE0078 from SPROM It seems Michaels theory about a missing sprom is correct. It gives me: [ 10.551127] ssb: Found rev 1 PMU (capabilities 0x02A62F01) [ 10.551143] ssb: Entering sprom_do_read [ 10.551152] ssb: Read 0x from SPROM [ 10.551159] ssb: Read 0x from SPROM What kind of device is that? Some laptop? I only knew about embedded devices using these wireless cards without sprom. Is the card connected via (mini)pci? Or is it on-board? What we need is a way to identify the card so we avoid accessing the dangling bus to the sprom. I'd like to avoid the read-the-first-word- and-check-if-its-all-ones approach, because accesses a dangling bus. That's obviously no good and can hang the CPU due to missing bus acks. What's the lspci -vvnn output for the card? -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
On Wednesday 18 November 2009 23:53:42 Michael Buesch wrote: On Wednesday 18 November 2009 23:07:29 Oncaphillis wrote: On 11/18/2009 06:51 PM, Larry Finger wrote: After you get access to the machine, please try my patch. It has been tested here. The first few lines from the output are: ssb: Entering sprom_do_read ssb: Read 0x2801 from SPROM ssb: Read 0x103C137C from SPROM ssb: Read 0x6DBE0078 from SPROM It seems Michaels theory about a missing sprom is correct. It gives me: [ 10.551127] ssb: Found rev 1 PMU (capabilities 0x02A62F01) [ 10.551143] ssb: Entering sprom_do_read [ 10.551152] ssb: Read 0x from SPROM [ 10.551159] ssb: Read 0x from SPROM What kind of device is that? Some laptop? I only knew about embedded devices using these wireless cards without sprom. Is the card connected via (mini)pci? Or is it on-board? What we need is a way to identify the card so we avoid accessing the dangling bus to the sprom. I'd like to avoid the read-the-first-word- and-check-if-its-all-ones approach, because accesses a dangling bus. That's obviously no good and can hang the CPU due to missing bus acks. What's the lspci -vvnn output for the card? Note that the chipcommon revision on the card is 0x16. That's a pretty high number. I wonder if they changed something and there actually _is_ an sprom on the card, but there's just a new way to access it (or the shadow area has to be mapped through chipcommon first or something like that)... -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
Please keep it on-list. This is really important to get this debugged properly. On Thursday 19 November 2009 00:23:18 Oncaphillis wrote: On 11/18/2009 11:59 PM, Michael Buesch wrote: What kind of device is that? Some laptop? I only knew about embedded devices using these wireless cards without sprom. Is the card connected via (mini)pci? Or is it on-board? What we need is a way to identify the card so we avoid accessing the dangling bus to the sprom. I'd like to avoid the read-the-first-word- and-check-if-its-all-ones approach, because accesses a dangling bus. That's obviously no good and can hang the CPU due to missing bus acks. What's the lspci -vvnn output for the card? Note that the chipcommon revision on the card is 0x16. That's a pretty high number. I wonder if they changed something and there actually _is_ an sprom on the card, but there's just a new way to access it (or the shadow area has to be mapped through chipcommon first or something like that)... It's an acer aspire one d250 netbook Nice. Is it possible to open the device and take a picture of the card? It's trivial to find out this way whether it has a SPROM or not, because it's a separate chip. Is it this device? http://hax0rpedia.com/index.php/Disassembeling_the_AAO_D250 Can you open the lower-right cover shown here: http://hax0rpedia.com/index.php/File:Aao_d250_step2.jpg and take a closeup picture of the wireless card? Also probably a picture of the backside of the card. That'd require removing the card, though. We really need to find out somehow if there is a SPROM chip on the device and if that's the case how to access it. You may have a look at the full lspci -vvnn output at: Nice, thanks. I did a read the first word. Surprisingly it succeeds the first time. After that I may still read 32bit words. When the module tries to read the sprom the second time looking for a larger sprom the first read16 fails. Well, my guess is that _any_ subsequent 16bit read would fail from then on, because it was still waiting for the bus-ack of the first one. If the bus really is dangling, we must avoid to access it in the first place. Should I try to dump out the full 16k area reported for the device ? I don't think that would be useful. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
On Thu, Nov 19, 2009 at 12:39 AM, Michael Buesch m...@bu3sch.de wrote: Please keep it on-list. This is really important to get this debugged properly. On Thursday 19 November 2009 00:23:18 Oncaphillis wrote: On 11/18/2009 11:59 PM, Michael Buesch wrote: What kind of device is that? Some laptop? I only knew about embedded devices using these wireless cards without sprom. Is the card connected via (mini)pci? Or is it on-board? What we need is a way to identify the card so we avoid accessing the dangling bus to the sprom. I'd like to avoid the read-the-first-word- and-check-if-its-all-ones approach, because accesses a dangling bus. That's obviously no good and can hang the CPU due to missing bus acks. What's the lspci -vvnn output for the card? Note that the chipcommon revision on the card is 0x16. That's a pretty high number. I wonder if they changed something and there actually _is_ an sprom on the card, but there's just a new way to access it (or the shadow area has to be mapped through chipcommon first or something like that)... It's an acer aspire one d250 netbook Nice. Is it possible to open the device and take a picture of the card? It's trivial to find out this way whether it has a SPROM or not, because it's a separate chip. Hmm... this kinda reminds me of when the SPROM died on my Asus 4318, causing it to display as a 14e4:0008, and freeze immediately upon any SPROM read/write attempt. Quite possibly we have something similar here (there is an SPROM, but it's broken - without an SPROM, the card AFAIK can't even produce a valid PCI ID). Is it this device? http://hax0rpedia.com/index.php/Disassembeling_the_AAO_D250 Can you open the lower-right cover shown here: http://hax0rpedia.com/index.php/File:Aao_d250_step2.jpg and take a closeup picture of the wireless card? Also probably a picture of the backside of the card. That'd require removing the card, though. We really need to find out somehow if there is a SPROM chip on the device and if that's the case how to access it. You may have a look at the full lspci -vvnn output at: Nice, thanks. I did a read the first word. Surprisingly it succeeds the first time. After that I may still read 32bit words. When the module tries to read the sprom the second time looking for a larger sprom the first read16 fails. Well, my guess is that _any_ subsequent 16bit read would fail from then on, because it was still waiting for the bus-ack of the first one. If the bus really is dangling, we must avoid to access it in the first place. Should I try to dump out the full 16k area reported for the device ? I don't think that would be useful. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
On 11/18/2009 05:57 PM, Gábor Stefanik wrote: Hmm... this kinda reminds me of when the SPROM died on my Asus 4318, causing it to display as a 14e4:0008, and freeze immediately upon any SPROM read/write attempt. Quite possibly we have something similar here (there is an SPROM, but it's broken - without an SPROM, the card AFAIK can't even produce a valid PCI ID). Does this card work with Windows or with the broadcom-wl driver on Linux? Certainly the latter would tell if there is a SPROM on the device. If wl does work, it would be useful to see an mmio dump for it. On my system, I can see the readout of the SPROM in that dump. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
Is it this device? http://hax0rpedia.com/index.php/Disassembeling_the_AAO_D250 Can you open the lower-right cover shown here: http://hax0rpedia.com/index.php/File:Aao_d250_step2.jpg and take a closeup picture of the wireless card? Also probably a picture of the backside of the card. That'd require removing the card, though. Hmm, surprise surprise. The slot is empty. They seem to have moved it onto the motherborad. Please don't ask me to look at this. My wife will kill me. The official type id on the back of the laptop is Acer One D250-0Bk Sebastian ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
On Thursday 19 November 2009 01:26:41 Oncaphillis wrote: Is it this device? http://hax0rpedia.com/index.php/Disassembeling_the_AAO_D250 Can you open the lower-right cover shown here: http://hax0rpedia.com/index.php/File:Aao_d250_step2.jpg and take a closeup picture of the wireless card? Also probably a picture of the backside of the card. That'd require removing the card, though. Hmm, surprise surprise. The slot is empty. They seem to have moved it onto the motherborad. Whoa, sick man. :) So I think there's a fair chance that there's no sprom at all, if the device is on-board. So I wonder how we can identify the device. I guess the four pci-IDs (vendor, device, subvendor, subdevice) are OK to do so? The next problem is where to get valid sprom data from? Do you have the original vendor driver on CD? If there's no sprom on the device, they must ship the sprom-image with the official driver. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
Michael Buesch wrote: Hmm, surprise surprise. The slot is empty. They seem to have moved it onto the motherborad. Whoa, sick man. :) So I think there's a fair chance that there's no sprom at all, if the device is on-board. One idea is to look up the FCC ID of the laptop in the FCC database. Since the radio is onboard, there should be photos of the internals in the application, which is usually available as PDF online. //Peter ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
