Re: b43 kills my kernel
On Monday 04 January 2010 22:51:40 Oncaphillis wrote: Did any of the patches for a device without a sprom make it into the 2.6.33-rc2 ? No we decided that the patches were not acceptable and need a rewrite towards firmware loading mechanism. Nobody's currently doing that, though. -- 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 01/05/2010 08:27 PM, Larry Finger wrote: On 01/05/2010 11:18 AM, Michael Buesch wrote: On Monday 04 January 2010 22:51:40 Oncaphillis wrote: Did any of the patches for a device without a sprom make it into the 2.6.33-rc2 ? No we decided that the patches were not acceptable and need a rewrite towards firmware loading mechanism. Nobody's currently doing that, though. Since the previous round of tests, the reverse-engineering group has been working on a new release of the Broadcom driver. So far, I have not looked into how it handles firmware when there is no SPROM, but that task is on my list of things to do. Larry Great to hear that. Thank you very much. I'll be happy to test it. and Happy new year ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
On 11/19/2009 12:30 PM, Michael Buesch wrote: On Thursday 19 November 2009 12:16:46 Oncaphillis wrote: On 11/19/2009 12:09 PM, Michael Buesch wrote: On Thursday 19 November 2009 12:07:30 Oncaphillis wrote: So I'm at a loss here, but if someone comes up with a bright idea to test or needs more informations I'm willing to test the resulting code on my machine. Erm, no. Can you please answer the questions that you didn't answer, yet? Especially the request for the original vendor driver. oh sorry. I did that, but the mail only went to larry -- stupid me -- the device didn't come with a CD/DVD and I killed Windows XP right away. Ok, very nice. -.- There are two major problems with not having an sprom: - We don't have the calibration data for the radio amplifiers. That could possibly be solved by providing a sane default set of data for a device type. - We don't have a MAC address for the card. This one is _very_ hard to solve properly. Several solutions come to mind, which are not really clean solutions: 1) We generate a random MAC. This would change on every reboot and break udev. The problem with this is obvious. 2) We generate the MAC by hashing some device-specific PCI config space values. I don't know if there are any device specific serial numbers or something similiar in PCI config space (or somewhere else). So the problem with this is that I don't know _what_ to hash. 3) We use the firmware loader to get an sprom image and have a userspace script take care of the generation of the image. The problem is the major inconvenience. Hi, Did any of the patches for a device without a sprom make it into the 2.6.33-rc2 ? Thank you. O. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
On Friday 20 November 2009 02:41:58 Oncaphillis wrote: On 11/20/2009 12:46 AM, Oncaphillis wrote: On 11/19/2009 06:44 PM, Michael Buesch wrote: On Thursday 19 November 2009 16:41:12 Michael Buesch wrote: Wait, that still can't work. I'll fix it soon... Ok, here's the updated version. Please test this: http://bu3sch.de/patches/wireless-testing/20091119-1842/patches/002-ssb-rewrite-sprom-fallback-mechanism.patch Heureka -- seems like I'm the first linux user on the planet with a WLAN connection on that device. The MAC address is random which of course is a pain for DHCP but it seems to work. Thanks. I'll see what I can do about this. [ 6415.479127] b43-phy0 debug: Removing Interface type 2 [ 6415.479601] b43-phy0 debug: Wireless interface stopped [ 6415.479615] b43-phy0 debug: DMA-64 rx_ring: Used slots 8/64, Failed frames 0/0 = 0.0%, Average tries 0.00 [ 6415.479710] b43-phy0 debug: DMA-64 tx_ring_AC_BK: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.0 [ 6415.481511] b43-phy0 debug: DMA-64 tx_ring_AC_BE: Used slots 152/256, Failed frames 2795/23615 = 11.8%, Averag tries 3.38 [ 6415.483077] b43-phy0 debug: DMA-64 tx_ring_AC_VI: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.0 [ 6415.485064] b43-phy0 debug: DMA-64 tx_ring_AC_VO: Used slots 12/256, Failed frames 35/2939 = 1.1%, Average tris 1.05 [ 6415.487069] b43-phy0 debug: DMA-64 tx_ring_mcast: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.0 and loose the interface Well, somebody shuts down the interfsce. There's nothing wrong with these logs. I would point at network manager 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
On 11/20/2009 10:27 AM, Michael Buesch wrote: On Friday 20 November 2009 02:41:58 Oncaphillis wrote: On 11/20/2009 12:46 AM, Oncaphillis wrote: On 11/19/2009 06:44 PM, Michael Buesch wrote: On Thursday 19 November 2009 16:41:12 Michael Buesch wrote: Wait, that still can't work. I'll fix it soon... Ok, here's the updated version. Please test this: http://bu3sch.de/patches/wireless-testing/20091119-1842/patches/002-ssb-rewrite-sprom-fallback-mechanism.patch Heureka -- seems like I'm the first linux user on the planet with a WLAN connection on that device. The MAC address is random which of course is a pain for DHCP but it seems to work. Thanks. I'll see what I can do about this. [ 6415.479127] b43-phy0 debug: Removing Interface type 2 [ 6415.479601] b43-phy0 debug: Wireless interface stopped [ 6415.479615] b43-phy0 debug: DMA-64 rx_ring: Used slots 8/64, Failed frames 0/0 = 0.0%, Average tries 0.00 [ 6415.479710] b43-phy0 debug: DMA-64 tx_ring_AC_BK: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.0 [ 6415.481511] b43-phy0 debug: DMA-64 tx_ring_AC_BE: Used slots 152/256, Failed frames 2795/23615 = 11.8%, Averag tries 3.38 [ 6415.483077] b43-phy0 debug: DMA-64 tx_ring_AC_VI: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.0 [ 6415.485064] b43-phy0 debug: DMA-64 tx_ring_AC_VO: Used slots 12/256, Failed frames 35/2939 = 1.1%, Average tris 1.05 [ 6415.487069] b43-phy0 debug: DMA-64 tx_ring_mcast: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.0 and loose the interface Well, somebody shuts down the interfsce. There's nothing wrong with these logs. I would point at network manager or something like that. Ok -- Some more details about my experience that it appears to be slow. As a test I've transfered a couple of 100 Mbyte files via NFS to my desktop. I don't know much about the overhead it has but if wlan0 tells me I have a 11MBit connection a throughput of at least 500kbyte/s should be possible and I'm far away from this. It also appeared that the transfer freezes for a couple of seconds ( I had a look at the file sizes on the recipient side in second intervals). Nothing suspicious in dmesg or syslog though. This of course is a very crude analysis, but if someone can point me to better tools to check for data throughput and connection stability I'll be happy to check in more detail. Sebastian ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
On Friday 20 November 2009 11:29:20 Oncaphillis wrote: Ok -- Some more details about my experience that it appears to be slow. Note that there are several issues. First one being the sprom calibration values being _wrong_ for your card. Second one is LP-PHY performance being crappy in general for the current implementation. Can somebody give me a genuine SPROM image for an LP-PHY card, please? Just do this: sudo cat $(find /sys/devices -name ssb_sprom) ssb_sprom_copy -- 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/20/2009 04:54 AM, Michael Buesch wrote: On Friday 20 November 2009 11:29:20 Oncaphillis wrote: Ok -- Some more details about my experience that it appears to be slow. Note that there are several issues. First one being the sprom calibration values being _wrong_ for your card. Second one is LP-PHY performance being crappy in general for the current implementation. Can somebody give me a genuine SPROM image for an LP-PHY card, please? Just do this: sudo cat $(find /sys/devices -name ssb_sprom) ssb_sprom_copy Real LP PHY, rev 8 SPROM image attached. Larry sprom.dat Description: MPEG movie ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
On 20/11/09 10:54, Michael Buesch wrote: Can somebody give me a genuine SPROM image for an LP-PHY card, please? Just do this: sudo cat $(find /sys/devices -name ssb_sprom) ssb_sprom_copy Does this help? Andy ssb_sprom_copy Description: Binary data ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
So I'm at a loss here, but if someone comes up with a bright idea to test or needs more informations I'm willing to test the resulting code on my machine. 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 12:07:30 Oncaphillis wrote: So I'm at a loss here, but if someone comes up with a bright idea to test or needs more informations I'm willing to test the resulting code on my machine. Erm, no. Can you please answer the questions that you didn't answer, yet? Especially the request for the original vendor 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
On 11/19/2009 12:09 PM, Michael Buesch wrote: On Thursday 19 November 2009 12:07:30 Oncaphillis wrote: So I'm at a loss here, but if someone comes up with a bright idea to test or needs more informations I'm willing to test the resulting code on my machine. Erm, no. Can you please answer the questions that you didn't answer, yet? Especially the request for the original vendor driver. oh sorry. I did that, but the mail only went to larry -- stupid me -- the device didn't come with a CD/DVD and I killed Windows XP right away. Sorry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
Erm, no. Can you please answer the questions that you didn't answer, yet? Especially the request for the original vendor driver. oh sorry. I did that, but the mail only went to larry -- stupid me -- the device didn't come with a CD/DVD and I killed Windows XP right away. Sorry But browsing through www.acer.de I ended up at http://global-download.acer.com/GDFiles%5CDriver/Wireless%20LAN/Wireless%20LAN_Broadcom_5.10.79.14_XPx86_A.zip?acerid=633864454005559398Step1=NetbookStep2=Aspire%20OneStep3=AOD250OS=X01LC=deBC=AcerSC=EMEA_8 which seems to give you the wlan drivers in a zip ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
Can you please try the following patch? http://bu3sch.de/patches/wireless-testing/20091119-1349/patches/002-ssb-rewrite-sprom-fallback-mechanism.patch -- 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/19/2009 01:49 PM, Michael Buesch wrote: Can you please try the following patch? http://bu3sch.de/patches/wireless-testing/20091119-1349/patches/002-ssb-rewrite-sprom-fallback-mechanism.patch That seems to freeze my kernel. I tell you more in a couple of hours. ___ 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 14:26:42 Oncaphillis wrote: On 11/19/2009 01:49 PM, Michael Buesch wrote: Can you please try the following patch? http://bu3sch.de/patches/wireless-testing/20091119-1349/patches/002-ssb-rewrite-sprom-fallback-mechanism.patch That seems to freeze my kernel. I tell you more in a couple of hours. There was a small thinko. Please test this one: http://bu3sch.de/patches/wireless-testing/20091119-1626/patches/002-ssb-rewrite-sprom-fallback-mechanism.patch -- 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 Thursday 19 November 2009 16:27:01 Michael Buesch wrote: On Thursday 19 November 2009 14:26:42 Oncaphillis wrote: On 11/19/2009 01:49 PM, Michael Buesch wrote: Can you please try the following patch? http://bu3sch.de/patches/wireless-testing/20091119-1349/patches/002-ssb-rewrite-sprom-fallback-mechanism.patch That seems to freeze my kernel. I tell you more in a couple of hours. There was a small thinko. Please test this one: http://bu3sch.de/patches/wireless-testing/20091119-1626/patches/002-ssb-rewrite-sprom-fallback-mechanism.patch Wait, that still can't work. I'll fix it soon... -- 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 Thursday 19 November 2009 16:41:12 Michael Buesch wrote: Wait, that still can't work. I'll fix it soon... Ok, here's the updated version. Please test this: http://bu3sch.de/patches/wireless-testing/20091119-1842/patches/002-ssb-rewrite-sprom-fallback-mechanism.patch -- 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/19/2009 06:44 PM, Michael Buesch wrote: On Thursday 19 November 2009 16:41:12 Michael Buesch wrote: Wait, that still can't work. I'll fix it soon... Ok, here's the updated version. Please test this: http://bu3sch.de/patches/wireless-testing/20091119-1842/patches/002-ssb-rewrite-sprom-fallback-mechanism.patch Heureka -- seems like I'm the first linux user on the planet with a WLAN connection on that device. The MAC address is random which of course is a pain for DHCP but it seems to work. Appears a little bit slow though. == iwconfig wlan0 IEEE 802.11bg ESSID:xx Mode:Managed Frequency:2.462 GHz Access Point: XX:XX:XX:XX:XX:XX Bit Rate=11 Mb/s Tx-Power=27 dBm Retry long limit:7 RTS thr:off Fragment thr:off Encryption key:off Power Management:off Link Quality=70/70 Signal level=7 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 I've x't out the access point info == ifconfig wlan0 Link encap:Ethernet HWaddr 92:09:86:56:1D:4E inet addr:192.168.XX.XX Bcast:192.168.XX.XX Mask:255.255.255.0 inet6 addr: :::::/xx Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3425 errors:0 dropped:0 overruns:0 frame:0 TX packets:4902 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:346201 (338.0 KiB) TX bytes:6049238 (5.7 MiB) No errors reported while I'm transfering stuff via nfs == # dmesg | grep -E '(b43|ssb)' [ 10.028898] b43-pci-bridge :01:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [ 10.028923] b43-pci-bridge :01:00.0: setting latency timer to 64 [ 10.036200] ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x16, vendor 0x4243) [ 10.036220] ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0F, vendor 0x4243) [ 10.036237] ssb: Core 2 found: PCMCIA (cc 0x80D, rev 0x0A, vendor 0x4243) [ 10.036253] ssb: Core 3 found: PCI-E (cc 0x820, rev 0x09, vendor 0x4243) [ 10.044137] ssb: Found rev 1 PMU (capabilities 0x02A62F01) [ 10.044165] ssb: Overriding SPROM image [ 10.052199] ssb: Sonics Silicon Backplane found on PCI device :01:00.0 [ 11.892104] b43-phy0: Broadcom 4312 WLAN found (core revision 15) [ 11.907112] b43-phy0 debug: Found PHY: Analog 6, Type 5, Revision 1 [ 11.907140] b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2062, Revision 2 [ 11.946392] Registered led device: b43-phy0::tx [ 11.946447] Registered led device: b43-phy0::rx [ 11.946501] Registered led device: b43-phy0::radio [ 28.361189] b43 ssb0:0: firmware: requesting b43/ucode15.fw [ 28.389230] b43 ssb0:0: firmware: requesting b43/lp0initvals15.fw [ 28.404838] b43 ssb0:0: firmware: requesting b43/lp0bsinitvals15.fw [ 28.564385] b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23) [ 28.566713] b43-phy0 debug: b2062: Using crystal tab entry 19200 kHz. [ 29.996192] b43-phy0 debug: Chip initialized [ 29.996623] b43-phy0 debug: 64-bit DMA initialized [ 29.996740] b43-phy0 debug: QoS enabled [ 30.006234] b43-phy0 debug: Wireless interface started [ 30.006297] b43-phy0 debug: Adding Interface type 2 == Thanks a 10^6. At least now I can hang out in bars while surfing the net. Sorry it took so long. I'll be happy if I can supply you with any information or patch more code into my kernel whenever I find the time. Cheers Sebastian ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
On 11/20/2009 12:46 AM, Oncaphillis wrote: On 11/19/2009 06:44 PM, Michael Buesch wrote: On Thursday 19 November 2009 16:41:12 Michael Buesch wrote: Wait, that still can't work. I'll fix it soon... Ok, here's the updated version. Please test this: http://bu3sch.de/patches/wireless-testing/20091119-1842/patches/002-ssb-rewrite-sprom-fallback-mechanism.patch Heureka -- seems like I'm the first linux user on the planet with a WLAN connection on that device. The MAC address is random which of course is a pain for DHCP but it seems to work. Appears a little bit slow though. Ok -- after a while of continous I get: [ 6415.479127] b43-phy0 debug: Removing Interface type 2 [ 6415.479601] b43-phy0 debug: Wireless interface stopped [ 6415.479615] b43-phy0 debug: DMA-64 rx_ring: Used slots 8/64, Failed frames 0/0 = 0.0%, Average tries 0.00 [ 6415.479710] b43-phy0 debug: DMA-64 tx_ring_AC_BK: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.0 [ 6415.481511] b43-phy0 debug: DMA-64 tx_ring_AC_BE: Used slots 152/256, Failed frames 2795/23615 = 11.8%, Averag tries 3.38 [ 6415.483077] b43-phy0 debug: DMA-64 tx_ring_AC_VI: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.0 [ 6415.485064] b43-phy0 debug: DMA-64 tx_ring_AC_VO: Used slots 12/256, Failed frames 35/2939 = 1.1%, Average tris 1.05 [ 6415.487069] b43-phy0 debug: DMA-64 tx_ring_mcast: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.0 and loose the interface :-( Cheers Sebastian ___ 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 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
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
Re: b43 kills my kernel
Thanks for posting the dmesg. In looking through it, the only thing I noticed was the following: [ 25.844834](523 KHz - 533 KHz @ 4 KHz), (600 mBi, 2300 mBm) [ 25.844844](5735000 KHz - 5835000 KHz @ 4 KHz), (600 mBi, 3000 mBm) [ 25.845455] cfg80211: Calling CRDA for country: US [ 26.115780] name_count maxed, losing inode data: dev=00:06, inode=13081 [ 26.115885] name_count maxed, losing inode data: dev=00:06, inode=13081 [ 26.115944] name_count maxed, losing inode data: dev=00:06, inode=13081 There are a lot of those name_count maxed messages. Is this a problem with your disk? Thanks for looking so closely -- although it's a little bit like if you go to the doctor for a flue remedy and (s|)he tells you you got tuberculosis :-). I think it's harmless. It comes from within auditsc.c. I've turned on everything in the kernel config that smelled like more verbosity and I think (hope ?) it's harmless. 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. So my guess is that the pci_dev passed to that function is not properly set up. I'll add more debug output into the module when i find the time and post the results. Sebastian ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
On 11/16/2009 05:03 PM, Oncaphillis wrote: Which gives: snip [9.972581] In sprom_do_read with sprom address 0xF8079000 /snip This address is also calculated in ssbioremap You may have a look at the full dmesg under: http://oncaphillis.net/dmesg-aspire-d250.txt Thanks for posting the dmesg. In looking through it, the only thing I noticed was the following: [ 25.844834] (523 KHz - 533 KHz @ 4 KHz), (600 mBi, 2300 mBm) [ 25.844844] (5735000 KHz - 5835000 KHz @ 4 KHz), (600 mBi, 3000 mBm) [ 25.845455] cfg80211: Calling CRDA for country: US [ 26.115780] name_count maxed, losing inode data: dev=00:06, inode=13081 [ 26.115885] name_count maxed, losing inode data: dev=00:06, inode=13081 [ 26.115944] name_count maxed, losing inode data: dev=00:06, inode=13081 There are a lot of those name_count maxed messages. Is this a problem with your disk? Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
On Saturday 14 November 2009 21:20:28 Michael Buesch wrote: Yeah, ok. That doesn't seem to be a bug in b43 then. It's the CRDA subsystem waiting for a userspace daemon. But it won't finish waiting, because userspace is not running, yet. I guess running cfg80211 as module is an acceptable workaround for now. We cannot reproduce this problem and it seems unlikely to be a CRDA issue, because it doesn't actually wait for userspace in that code. So we won't investigate further on this issue for now, as long as there's no new information on how to reproduce this. -- 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/15/2009 03:40 PM, Michael Buesch wrote:
On Saturday 14 November 2009 21:20:28 Michael Buesch wrote:
Yeah, ok. That doesn't seem to be a bug in b43 then. It's the CRDA subsystem
waiting for a userspace daemon. But it won't finish waiting, because
userspace
is not running, yet. I guess running cfg80211 as module is an acceptable
workaround for now.
We cannot reproduce this problem and it seems unlikely to be a CRDA issue,
because
it doesn't actually wait for userspace in that code.
So we won't investigate further on this issue for now, as long as there's no
new information
on how to reproduce this.
Here's a little update on the issue. It isn't b43 that freezes the
system but ssb.ko, but only if the B43 option is set. I poked around
in the sbb code and found that ssb_do_read never returns:
snip
static int sprom_do_read(struct ssb_bus *bus, u16 *sprom)
{
int i;
for (i = 0; i bus-sprom_size; i++)
sprom[i] = ioread16(bus-mmio + SSB_SPROM_BASE + (i * 2));
return 0;
}
/snip
So I guess the mmio address is wrong. It is set to decimal -133791744
when it freezes. I don't know if that's a valid mmio address but it
seems fishy.
Sebastian
Here comes a lspci -vvnn
snip
00:00.0 Host bridge [0600]: Intel Corporation Mobile 945GME Express
Memory Controller Hub [8086:27ac] (rev 03)
Subsystem: Acer Incorporated [ALI] Device [1025:022f]
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
Capabilities: [e0] Vendor Specific Information ?
Kernel driver in use: agpgart-intel
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile
945GME Express Integrated Graphics Controller [8086:27ae] (rev 03)
(prog-if 00 [VGA controller])
Subsystem: Acer Incorporated [ALI] Device [1025:022f]
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
Interrupt: pin A routed to IRQ 11
Region 0: Memory at 5828 (32-bit, non-prefetchable)
[size=512K]
Region 1: I/O ports at 60f0 [size=8]
Region 2: Memory at 4000 (32-bit, prefetchable) [size=256M]
Region 3: Memory at 5830 (32-bit, non-prefetchable)
[size=256K]
Expansion ROM at unassigned [disabled]
Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit-
Address: Data:
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
00:02.1 Display controller [0380]: Intel Corporation Mobile
945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller
[8086:27a6] (rev 03)
Subsystem: Acer Incorporated [ALI] Device [1025:022f]
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
Region 0: Memory at 5820 (32-bit, non-prefetchable)
[size=512K]
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
00:1b.0 Audio device [0403]: Intel Corporation 82801G (ICH7 Family) High
Definition Audio Controller [8086:27d8] (rev 02)
Subsystem: Acer Incorporated [ALI] Device [1025:022f]
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
Interrupt: pin A routed to IRQ 16
Region 0: Memory at 5834 (64-bit, non-prefetchable)
[size=16K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [60] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: Data:
Capabilities: [70] Express (v1) Root Complex Integrated
Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s
64ns, L1 1us
ExtTag- RBE- FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
Re: b43 kills my kernel
Oncaphillis wrote:
I poked around in the sbb code and found that ssb_do_read never
returns:
snip
static int sprom_do_read(struct ssb_bus *bus, u16 *sprom)
You wrote ssb_do_read above, this is sprom_do_read. Maybe they call
each other?
So I guess the mmio address is wrong. It is set to decimal
-133791744 when it freezes. I don't know if that's a valid mmio
address but it seems fishy.
$ printf %x\\n -133791744 | sed 'sx.*\(.\{8\}\)x\1x'
f8068000
Basically looks ok, but..
01:00.0 Network controller [0280]: Broadcom Corporation BCM4312 802.11b/g
[14e4:4315] (rev 01)
..
Region 0: Memory at 5710 (64-bit, non-prefetchable) [size=16K]
It should be closer to this region.
//Peter
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
On 11/13/2009 08:20 PM, Larry Finger wrote: On 11/13/2009 11:46 AM, Oncaphillis wrote: Thanks for the tip. But it still hangs We still need to know where it hangs. If you boot to console mode (type a 3 on the option line in GRUB), does it boot? If it does not, what is the last line shown on the console? If your distro shows a splash screen while booting, get rid of it by typing an ESC after booting starts, or eliminate the splash=silent option on the boot line. If the previous boot works, log into your usual account. That should still work. Next you should type the command startx and immediately press the keys CRTL-ALT-F10. That is hold the CTRL and ALT keys while pressing the F10 key. The display should shift to the log console. When the computer freezes, report what you see on the screen. It will not scroll, nor can you save it. Write it down by hand or take a picture. Report what happens. If some of these steps don't work on your computer, please tell what distro you are using. Larry So now I've stripped down the kernel quite a lot and added as many debug options that seem to make sense to me. No ACPI at all and no network device driver except for b43, including low eneregy optins, and PIO mode. If I leave out the b43 driver the kernel boots just fine. If I include it I get the following on the screen: http://oncaphillis.net/IMG_0214.JPG So it seems to me it doesn't even reach the loading of p43.ko but gets stuck in the cfg80211 layer. Any further hints how to proceed in debugging this. Sebastian ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
On 11/14/2009 12:24 PM, Oncaphillis wrote: On 11/13/2009 08:20 PM, Larry Finger wrote: On 11/13/2009 11:46 AM, Oncaphillis wrote: Thanks for the tip. But it still hangs We still need to know where it hangs. If you boot to console mode (type a 3 on the option line in GRUB), does it boot? If it does not, what is the last line shown on the console? If your distro shows a splash screen while booting, get rid of it by typing an ESC after booting starts, or eliminate the splash=silent option on the boot line. If the previous boot works, log into your usual account. That should still work. Next you should type the command startx and immediately press the keys CRTL-ALT-F10. That is hold the CTRL and ALT keys while pressing the F10 key. The display should shift to the log console. When the computer freezes, report what you see on the screen. It will not scroll, nor can you save it. Write it down by hand or take a picture. Report what happens. If some of these steps don't work on your computer, please tell what distro you are using. Larry So now I've stripped down the kernel quite a lot and added as many debug options that seem to make sense to me. No ACPI at all and no network device driver except for b43, including low eneregy optins, and PIO mode. If I leave out the b43 driver the kernel boots just fine. If I include it I get the following on the screen: http://oncaphillis.net/IMG_0214.JPG So it seems to me it doesn't even reach the loading of p43.ko but gets stuck in the cfg80211 layer. And the same holds true with the patch 20091113 Any further hints how to proceed in debugging this. Sebastian ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
On 11/14/2009 07:37 AM, Oncaphillis wrote: So it seems to me it doesn't even reach the loading of p43.ko but gets stuck in the cfg80211 layer. We can test that hypothesis. Generate a kernel without b43. Once it boots, enter the following commands as root: modprobe -v rfkill modprobe -v cfg80211 modprobe -v mac80211 modprobe -v ssb That will load the modules one by one. 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/14/2009 04:42 PM, Larry Finger wrote: On 11/14/2009 07:37 AM, Oncaphillis wrote: So it seems to me it doesn't even reach the loading of p43.ko but gets stuck in the cfg80211 layer. We can test that hypothesis. Generate a kernel without b43. Once it boots, enter the following commands as root: modprobe -v rfkill modprobe -v cfg80211 modprobe -v mac80211 modprobe -v ssb Hmm...works fine with the following dmesg: snip [ 490.563574] cfg80211: Using static regulatory domain info [ 490.563582] cfg80211: Regulatory domain: US [ 490.563588] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 490.563596] (2402000 KHz - 2472000 KHz @ 4 KHz), (600 mBi, 2700 mBm) [ 490.563603] (517 KHz - 519 KHz @ 4 KHz), (600 mBi, 2300 mBm) [ 490.563610] (519 KHz - 521 KHz @ 4 KHz), (600 mBi, 2300 mBm) [ 490.563617] (521 KHz - 523 KHz @ 4 KHz), (600 mBi, 2300 mBm) [ 490.563624] (523 KHz - 533 KHz @ 4 KHz), (600 mBi, 2300 mBm) [ 490.563631] (5735000 KHz - 5835000 KHz @ 4 KHz), (600 mBi, 3000 mBm) [ 490.567612] cfg80211: Calling CRDA for country: US [ 490.643438] cfg80211: Regulatory domain changed to country: US [ 490.643446] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 490.643455] (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2700 mBm) [ 490.643462] (517 KHz - 525 KHz @ 4 KHz), (300 mBi, 1700 mBm) [ 490.643469] (525 KHz - 533 KHz @ 4 KHz), (300 mBi, 2000 mBm) [ 490.643476] (549 KHz - 560 KHz @ 4 KHz), (300 mBi, 2000 mBm) [ 490.643483] (565 KHz - 571 KHz @ 4 KHz), (300 mBi, 2000 mBm) [ 490.643490] (5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 3000 mBm) /snip Even more surprising if I compile b43.ko separately afterwards and insert it via insmod it gets inserted without any failure, giving me [ 539.795403] Broadcom 43xx driver loaded [ Features: PL, Firmware-ID: FW13 ] but I don't see any wlan device. Next step I do is to offer a firmware file. dialect value=austrian I'll be back /dialect Sebastian That will load the modules one by one. 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/14/2009 08:45 PM, Michael Buesch wrote: On Saturday 14 November 2009 12:24:24 Oncaphillis wrote: On 11/13/2009 08:20 PM, Larry Finger wrote: On 11/13/2009 11:46 AM, Oncaphillis wrote: Thanks for the tip. But it still hangs We still need to know where it hangs. If you boot to console mode (type a 3 on the option line in GRUB), does it boot? If it does not, what is the last line shown on the console? If your distro shows a splash screen while booting, get rid of it by typing an ESC after booting starts, or eliminate the splash=silent option on the boot line. If the previous boot works, log into your usual account. That should still work. Next you should type the command startx and immediately press the keys CRTL-ALT-F10. That is hold the CTRL and ALT keys while pressing the F10 key. The display should shift to the log console. When the computer freezes, report what you see on the screen. It will not scroll, nor can you save it. Write it down by hand or take a picture. Report what happens. If some of these steps don't work on your computer, please tell what distro you are using. Larry So now I've stripped down the kernel quite a lot and added as many debug options that seem to make sense to me. No ACPI at all and no network device driver except for b43, including low eneregy optins, and PIO mode. If I leave out the b43 driver the kernel boots just fine. If I include it I get the following on the screen: http://oncaphillis.net/IMG_0214.JPG So it seems to me it doesn't even reach the loading of p43.ko but gets stuck in the cfg80211 layer. Well, there's a TSC message after that, which is completely unrelated to cfg80211. It could possibly be sleeping in the CRDA call and executes the TSC stuff in parallel (given that the TSC message is only a few microseconds later). I don't really know how parallelization is done here (if any). Any further hints how to proceed in debugging this. Do you have cfg80211/mac80211 built-in or as modules? The TSC message after the cfg80211 message might indicate that it's built-in. It used to be build in, but I successfully built and inserted all components (including b43) as a module (see my previous message ). It's basically impossible to tell what's going on here. You could do a git bisection to track down the bad commit. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
On Saturday 14 November 2009 12:24:24 Oncaphillis wrote: On 11/13/2009 08:20 PM, Larry Finger wrote: On 11/13/2009 11:46 AM, Oncaphillis wrote: Thanks for the tip. But it still hangs We still need to know where it hangs. If you boot to console mode (type a 3 on the option line in GRUB), does it boot? If it does not, what is the last line shown on the console? If your distro shows a splash screen while booting, get rid of it by typing an ESC after booting starts, or eliminate the splash=silent option on the boot line. If the previous boot works, log into your usual account. That should still work. Next you should type the command startx and immediately press the keys CRTL-ALT-F10. That is hold the CTRL and ALT keys while pressing the F10 key. The display should shift to the log console. When the computer freezes, report what you see on the screen. It will not scroll, nor can you save it. Write it down by hand or take a picture. Report what happens. If some of these steps don't work on your computer, please tell what distro you are using. Larry So now I've stripped down the kernel quite a lot and added as many debug options that seem to make sense to me. No ACPI at all and no network device driver except for b43, including low eneregy optins, and PIO mode. If I leave out the b43 driver the kernel boots just fine. If I include it I get the following on the screen: http://oncaphillis.net/IMG_0214.JPG So it seems to me it doesn't even reach the loading of p43.ko but gets stuck in the cfg80211 layer. Well, there's a TSC message after that, which is completely unrelated to cfg80211. It could possibly be sleeping in the CRDA call and executes the TSC stuff in parallel (given that the TSC message is only a few microseconds later). I don't really know how parallelization is done here (if any). Any further hints how to proceed in debugging this. Do you have cfg80211/mac80211 built-in or as modules? The TSC message after the cfg80211 message might indicate that it's built-in. It's basically impossible to tell what's going on here. You could do a git bisection to track down the bad commit. -- 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 Saturday 14 November 2009 21:03:09 Oncaphillis wrote: On 11/14/2009 08:45 PM, Michael Buesch wrote: On Saturday 14 November 2009 12:24:24 Oncaphillis wrote: On 11/13/2009 08:20 PM, Larry Finger wrote: On 11/13/2009 11:46 AM, Oncaphillis wrote: Thanks for the tip. But it still hangs We still need to know where it hangs. If you boot to console mode (type a 3 on the option line in GRUB), does it boot? If it does not, what is the last line shown on the console? If your distro shows a splash screen while booting, get rid of it by typing an ESC after booting starts, or eliminate the splash=silent option on the boot line. If the previous boot works, log into your usual account. That should still work. Next you should type the command startx and immediately press the keys CRTL-ALT-F10. That is hold the CTRL and ALT keys while pressing the F10 key. The display should shift to the log console. When the computer freezes, report what you see on the screen. It will not scroll, nor can you save it. Write it down by hand or take a picture. Report what happens. If some of these steps don't work on your computer, please tell what distro you are using. Larry So now I've stripped down the kernel quite a lot and added as many debug options that seem to make sense to me. No ACPI at all and no network device driver except for b43, including low eneregy optins, and PIO mode. If I leave out the b43 driver the kernel boots just fine. If I include it I get the following on the screen: http://oncaphillis.net/IMG_0214.JPG So it seems to me it doesn't even reach the loading of p43.ko but gets stuck in the cfg80211 layer. Well, there's a TSC message after that, which is completely unrelated to cfg80211. It could possibly be sleeping in the CRDA call and executes the TSC stuff in parallel (given that the TSC message is only a few microseconds later). I don't really know how parallelization is done here (if any). Any further hints how to proceed in debugging this. Do you have cfg80211/mac80211 built-in or as modules? The TSC message after the cfg80211 message might indicate that it's built-in. It used to be build in, but I successfully built and inserted all components (including b43) as a module (see my previous message ). Yeah, ok. That doesn't seem to be a bug in b43 then. It's the CRDA subsystem waiting for a userspace daemon. But it won't finish waiting, because userspace is not running, yet. I guess running cfg80211 as module is an acceptable workaround for now. About your device is not created problem: Please enable CONFIG_SSB_DEBUG, reboot and send the result. Also send the output of lspci -vvn. -- 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/13/2009 09:33 AM, Oncaphillis wrote: Hi, I have a Acer One D250 which is equipped with a BCM4312 for which on the homepage the support is marked as in progress. Whenever the kernel tries to insert b43.ko it freezes. If've moved up to 2.6.32-rc7, but is always stays like this. snip source=lspci -vnn 01:00.0 Network controller [0280]: Broadcom Corporation BCM4312 802.11b/g [14e4:4315] (rev 01) Subsystem: Foxconn International, Inc. Device [105b:e01b] Flags: bus master, fast devsel, latency 0, IRQ 11 Memory at 5710 (64-bit, non-prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [58] Vendor Specific Information ? Capabilities: [e8] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [d0] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [13c] Virtual Channel ? Capabilities: [160] Device Serial Number 00-00-00-ff-ff-00-ff-ff Capabilities: [16c] Power Budgeting ? /snip Could someone tell me what is the best way to debug this ? May be there is a SVN from where to pull the most up to date sources so I could poke a little bit to find out where it hangs. I'm beginning to hate ATOM-based netbooks. The most up to date sources are in wireless-testing - a git repository; however, there are few differences between w-t and Linus's sources. Does it boot with acpi=off added to the boot line? 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/13/2009 05:12 PM, Larry Finger wrote: On 11/13/2009 09:33 AM, Oncaphillis wrote: Hi, I have a Acer One D250 which is equipped with a BCM4312 for which on the homepage the support is marked as in progress. Whenever the kernel tries to insert b43.ko it freezes. If've moved up to 2.6.32-rc7, but is always stays like this. snip source=lspci -vnn 01:00.0 Network controller [0280]: Broadcom Corporation BCM4312 802.11b/g [14e4:4315] (rev 01) Subsystem: Foxconn International, Inc. Device [105b:e01b] Flags: bus master, fast devsel, latency 0, IRQ 11 Memory at 5710 (64-bit, non-prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [58] Vendor Specific Information? Capabilities: [e8] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [d0] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [13c] Virtual Channel? Capabilities: [160] Device Serial Number 00-00-00-ff-ff-00-ff-ff Capabilities: [16c] Power Budgeting? /snip Could someone tell me what is the best way to debug this ? May be there is a SVN from where to pull the most up to date sources so I could poke a little bit to find out where it hangs. I'm beginning to hate ATOM-based netbooks. The most up to date sources are in wireless-testing - a git repository; however, there are few differences between w-t and Linus's sources. Does it boot with acpi=off added to the boot line? Nope Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
On Friday 13 November 2009 17:41:21 Oncaphillis wrote: On 11/13/2009 05:12 PM, Larry Finger wrote: On 11/13/2009 09:33 AM, Oncaphillis wrote: Hi, I have a Acer One D250 which is equipped with a BCM4312 for which on the homepage the support is marked as in progress. Whenever the kernel tries to insert b43.ko it freezes. If've moved up to 2.6.32-rc7, but is always stays like this. snip source=lspci -vnn 01:00.0 Network controller [0280]: Broadcom Corporation BCM4312 802.11b/g [14e4:4315] (rev 01) Subsystem: Foxconn International, Inc. Device [105b:e01b] Flags: bus master, fast devsel, latency 0, IRQ 11 Memory at 5710 (64-bit, non-prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [58] Vendor Specific Information? Capabilities: [e8] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [d0] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [13c] Virtual Channel? Capabilities: [160] Device Serial Number 00-00-00-ff-ff-00-ff-ff Capabilities: [16c] Power Budgeting? /snip Could someone tell me what is the best way to debug this ? May be there is a SVN from where to pull the most up to date sources so I could poke a little bit to find out where it hangs. I'm beginning to hate ATOM-based netbooks. The most up to date sources are in wireless-testing - a git repository; however, there are few differences between w-t and Linus's sources. Does it boot with acpi=off added to the boot line? Nope Does it really freeze, or are you in X and just don't see the Oops message? If it does freeze, _where_ does it freeze? What are the last kernel messages? Got a camera to take a picture? -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
Oncaphillis wrote: On 11/13/2009 05:12 PM, Larry Finger wrote: On 11/13/2009 09:33 AM, Oncaphillis wrote: Hi, I have a Acer One D250 which is equipped with a BCM4312 for which on the homepage the support is marked as in progress. Whenever the kernel tries to insert b43.ko it freezes. If've moved up to 2.6.32-rc7, but is always stays like this. snip source=lspci -vnn 01:00.0 Network controller [0280]: Broadcom Corporation BCM4312 802.11b/g [14e4:4315] (rev 01) Subsystem: Foxconn International, Inc. Device [105b:e01b] Flags: bus master, fast devsel, latency 0, IRQ 11 Memory at 5710 (64-bit, non-prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [58] Vendor Specific Information? Capabilities: [e8] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [d0] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [13c] Virtual Channel? Capabilities: [160] Device Serial Number 00-00-00-ff-ff-00-ff-ff Capabilities: [16c] Power Budgeting? /snip Could someone tell me what is the best way to debug this ? May be there is a SVN from where to pull the most up to date sources so I could poke a little bit to find out where it hangs. I'm beginning to hate ATOM-based netbooks. The most up to date sources are in wireless-testing - a git repository; however, there are few differences between w-t and Linus's sources. Does it boot with acpi=off added to the boot line? Nope Larry Just a hints, my own 4312 card is unusable if I don't force PIO... still my kernel won't crash thought. You might want to recompile to set B43_FORCE_PIO (Force usage of PIO instead of DMA) to yes. It is under CONFIG_B43_DEBUG (Broadcom 43xx debugging). It won't fix anything, it will be slow as hell, but you might be able to boot, I guess. - William ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
On 11/13/2009 05:56 PM, William Bourque wrote: Oncaphillis wrote: On 11/13/2009 05:12 PM, Larry Finger wrote: On 11/13/2009 09:33 AM, Oncaphillis wrote: Hi, I have a Acer One D250 which is equipped with a BCM4312 for which on the homepage the support is marked as in progress. Whenever the kernel tries to insert b43.ko it freezes. If've moved up to 2.6.32-rc7, but is always stays like this. snip source=lspci -vnn 01:00.0 Network controller [0280]: Broadcom Corporation BCM4312 802.11b/g [14e4:4315] (rev 01) Subsystem: Foxconn International, Inc. Device [105b:e01b] Flags: bus master, fast devsel, latency 0, IRQ 11 Memory at 5710 (64-bit, non-prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [58] Vendor Specific Information? Capabilities: [e8] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [d0] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [13c] Virtual Channel? Capabilities: [160] Device Serial Number 00-00-00-ff-ff-00-ff-ff Capabilities: [16c] Power Budgeting? /snip Could someone tell me what is the best way to debug this ? May be there is a SVN from where to pull the most up to date sources so I could poke a little bit to find out where it hangs. I'm beginning to hate ATOM-based netbooks. The most up to date sources are in wireless-testing - a git repository; however, there are few differences between w-t and Linus's sources. Does it boot with acpi=off added to the boot line? Nope Larry Just a hints, my own 4312 card is unusable if I don't force PIO... still my kernel won't crash thought. You might want to recompile to set B43_FORCE_PIO (Force usage of PIO instead of DMA) to yes. It is under CONFIG_B43_DEBUG (Broadcom 43xx debugging). It won't fix anything, it will be slow as hell, but you might be able to boot, I guess. Thanks for the tip. But it still hangs - William ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
On Friday 13 November 2009 18:46:22 Oncaphillis wrote: Thanks for the tip. But it still hangs So, any chance to tell us what hangs means? See my other mail. -- 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/13/2009 11:46 AM, Oncaphillis wrote: Thanks for the tip. But it still hangs We still need to know where it hangs. If you boot to console mode (type a 3 on the option line in GRUB), does it boot? If it does not, what is the last line shown on the console? If your distro shows a splash screen while booting, get rid of it by typing an ESC after booting starts, or eliminate the splash=silent option on the boot line. If the previous boot works, log into your usual account. That should still work. Next you should type the command startx and immediately press the keys CRTL-ALT-F10. That is hold the CTRL and ALT keys while pressing the F10 key. The display should shift to the log console. When the computer freezes, report what you see on the screen. It will not scroll, nor can you save it. Write it down by hand or take a picture. Report what happens. If some of these steps don't work on your computer, please tell what distro you are using. 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/13/2009 08:20 PM, Larry Finger wrote: On 11/13/2009 11:46 AM, Oncaphillis wrote: Thanks for the tip. But it still hangs We still need to know where it hangs. If you boot to console mode (type a 3 on the option line in GRUB), does it boot? If it does not, what is the last line shown on the console? If your distro shows a splash screen while booting, get rid of it by typing an ESC after booting starts, or eliminate the splash=silent option on the boot line. If the previous boot works, log into your usual account. That should still work. Next you should type the command startx and immediately press the keys CRTL-ALT-F10. That is hold the CTRL and ALT keys while pressing the F10 key. The display should shift to the log console. When the computer freezes, report what you see on the screen. It will not scroll, nor can you save it. Write it down by hand or take a picture. Sorry for not giving the details. I'm using Fedora 11 with 2.6.32-rc7 kernel. I've turned of the splash screen and boot into runlevel 3. The last line I see is that the distro tries to start up udev -- No oops or such thing. I also did the following -- (1) removed the whole /lib/modules/XXX/ tree and booted into the kernel. (2) Made make modules_install;depmod -a. If I do a modprobe b43 it still freezes without any further message. Surprisingly if I only remove b43.ko from the module tree it still hangs on reboot. Looks like a inter module problem to me. The only other modules I hold are arl1.ko, atl1e.ko,atl1c.ko mii.ko and scsi_wait_scan.ko but the only one being loaded seems to be atl1c.ko I actually do not have any firmware installed yet and I had a look at the code ( also I'm not a kernel hacker) and I see that it should bail out properly if it fails to find (and|or) initialize the firmware. So it seems to fail quite early. There used to be a kernel option that makes it extra verbose. What was that ? Thanks Sebastian Report what happens. If some of these steps don't work on your computer, please tell what distro you are using. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
On Friday 13 November 2009 21:36:31 Oncaphillis wrote: On 11/13/2009 08:20 PM, Larry Finger wrote: On 11/13/2009 11:46 AM, Oncaphillis wrote: Thanks for the tip. But it still hangs We still need to know where it hangs. If you boot to console mode (type a 3 on the option line in GRUB), does it boot? If it does not, what is the last line shown on the console? If your distro shows a splash screen while booting, get rid of it by typing an ESC after booting starts, or eliminate the splash=silent option on the boot line. If the previous boot works, log into your usual account. That should still work. Next you should type the command startx and immediately press the keys CRTL-ALT-F10. That is hold the CTRL and ALT keys while pressing the F10 key. The display should shift to the log console. When the computer freezes, report what you see on the screen. It will not scroll, nor can you save it. Write it down by hand or take a picture. Sorry for not giving the details. I'm using Fedora 11 with 2.6.32-rc7 kernel. I've turned of the splash screen and boot into runlevel 3. The last line I see is that the distro tries to start up udev -- No oops or such thing. I also did the following -- (1) removed the whole /lib/modules/XXX/ tree and booted into the kernel. (2) Made make modules_install;depmod -a. If I do a modprobe b43 it still freezes without any further message. Surprisingly if I only remove b43.ko from the module tree it still hangs on reboot. Looks like a inter module problem to me. The only other Looks like not related to b43, to me. You could try to enable most of the kernel debugging options in the kernel hacking menu. Memory corruption, lock debugging and softlockup detection options are the most interesting. -- 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/13/2009 09:43 PM, Michael Buesch wrote: On Friday 13 November 2009 21:36:31 Oncaphillis wrote: On 11/13/2009 08:20 PM, Larry Finger wrote: On 11/13/2009 11:46 AM, Oncaphillis wrote: Thanks for the tip. But it still hangs We still need to know where it hangs. If you boot to console mode (type a 3 on the option line in GRUB), does it boot? If it does not, what is the last line shown on the console? If your distro shows a splash screen while booting, get rid of it by typing an ESC after booting starts, or eliminate the splash=silent option on the boot line. If the previous boot works, log into your usual account. That should still work. Next you should type the command startx and immediately press the keys CRTL-ALT-F10. That is hold the CTRL and ALT keys while pressing the F10 key. The display should shift to the log console. When the computer freezes, report what you see on the screen. It will not scroll, nor can you save it. Write it down by hand or take a picture. Sorry for not giving the details. I'm using Fedora 11 with 2.6.32-rc7 kernel. I've turned of the splash screen and boot into runlevel 3. The last line I see is that the distro tries to start up udev -- No oops or such thing. I also did the following -- (1) removed the whole /lib/modules/XXX/ tree and booted into the kernel. (2) Made make modules_install;depmod -a. If I do a modprobe b43 it still freezes without any further message. Surprisingly if I only remove b43.ko from the module tree it still hangs on reboot. Looks like a inter module problem to me. The only other Looks like not related to b43, to me. Yes -- but if I leave the kernel config like it is and only leave out b43 it boots fine. You could try to enable most of the kernel debugging options in the kernel hacking menu. Memory corruption, lock debugging and softlockup detection options are the most interesting. I'll give that a try. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
On 11/13/2009 03:02 PM, Oncaphillis wrote: On 11/13/2009 09:43 PM, Michael Buesch wrote: On Friday 13 November 2009 21:36:31 Oncaphillis wrote: On 11/13/2009 08:20 PM, Larry Finger wrote: On 11/13/2009 11:46 AM, Oncaphillis wrote: Thanks for the tip. But it still hangs We still need to know where it hangs. If you boot to console mode (type a 3 on the option line in GRUB), does it boot? If it does not, what is the last line shown on the console? If your distro shows a splash screen while booting, get rid of it by typing an ESC after booting starts, or eliminate the splash=silent option on the boot line. If the previous boot works, log into your usual account. That should still work. Next you should type the command startx and immediately press the keys CRTL-ALT-F10. That is hold the CTRL and ALT keys while pressing the F10 key. The display should shift to the log console. When the computer freezes, report what you see on the screen. It will not scroll, nor can you save it. Write it down by hand or take a picture. Sorry for not giving the details. I'm using Fedora 11 with 2.6.32-rc7 kernel. I've turned of the splash screen and boot into runlevel 3. The last line I see is that the distro tries to start up udev -- No oops or such thing. I also did the following -- (1) removed the whole /lib/modules/XXX/ tree and booted into the kernel. (2) Made make modules_install;depmod -a. If I do a modprobe b43 it still freezes without any further message. Surprisingly if I only remove b43.ko from the module tree it still hangs on reboot. Looks like a inter module problem to me. The only other Looks like not related to b43, to me. Yes -- but if I leave the kernel config like it is and only leave out b43 it boots fine. You could try to enable most of the kernel debugging options in the kernel hacking menu. Memory corruption, lock debugging and softlockup detection options are the most interesting. I'll give that a try. PLease look at the files in /etc/udev/rules.d. Any of those involved? Certainly the persistent network rules will be involved. I'm not sure of the name. On my system, it is 70-persistent-network.rules. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
