On 03/26/2013 07:43 PM, John Talbut wrote: > On 26/03/13 16:59, Rafał Miłecki wrote: >> 2013/3/26 Arend van Spriel<arend@xxxxxxxxxxxx>: >>> On 03/26/2013 12:43 PM, John Talbut wrote: >>>> On 26/03/13 11:29, Arend van Spriel wrote: >>>>> On 03/26/2013 12:13 PM, John Talbut wrote: >>>>>> >>>>>> On 26/03/13 10:53, Arend van Spriel wrote: >>>>>>> On 03/26/2013 11:34 AM, John Talbut wrote: >>>>>>>> Kernel log attached. >>>>>>>> >>>>>>> >>>>>>> Now this is weird. I do not see any BCMA log messages. Can you give >>>>>>> output of following command: >>>>>>> >>>>>>> $ lspci -n -s 1:0.0 >>>>>> >>>>>> 01:00.0 0280: 14e4:4357 (rev 01) >>>>> >>>>> Ok, no problem there. >>>>> >>>>> digging further in sysfs. Can you execute the following commands: >>>>> >>>>> if it exists: >>>>> $ ls /sys/bus/bcma >>>>> $ ls /sys/bus/bcma/devices >>>>> $ ls /sys/bus/bcma/drivers >>>>> >>>>> if it exists also following: >>>>> $ ls -l /sys/bus/bcma/drivers/brcmsmac >>>> >>>> root@johnwtnc110:/usr/src/linux-source-3.8# ls /sys/bus/bcma >>>> devices drivers drivers_autoprobe drivers_probe uevent >>>> root@johnwtnc110:/usr/src/linux-source-3.8# ls /sys/bus/bcma/devices >>> >>> The fact that there are no devices detected under bcma is suspicious. >>> Adding bcma developer to the list. Maybe he knows about issues when >>> having bcma compiled in kernel image. >> >> Thanks Arend. Unfortunately I can't find archive of this thread, so I >> can see only quotations above. >> >> If there is /sys/bus/bcma/ directory, it means bcma had to be loaded >> (or just is built into the kernel). However if there are no "bcma" >> messages in the dmesg, it's probably because there isn't any device >> bcma (currently) handles. >> >> If you can it yourself: remove all 14e4:* devices and do "modprobe >> bcma". You will get /sys/bus/bcma/ without "bcma" messages in dmesg. >> >> 14e4:4357 is one of the devices handled by bcma, so there are two >> options: >> 1) It's some old kernel where we didn't have 14e4:4357 in bcma >> 2) There is another module that grabbed 14e4:4357 PCI device >> >> The first option can be verified with "modinfo bcma | grep alias" in >> case of bcma as a module. Not sure how to check that for bcma built >> in. >> >> The second option is even easier to verify, just use: >> lspci -d 14e4: -v >> and check for "Kernel driver in use: " >> > Thanks Rafał. > > I have everything built into the kernel which is compiled using the 3.8 > kernel source from Debian, so not an old kernel. > > ls /sys/bus/bcma > devices drivers drivers_autoprobe drivers_probe uevent > > lspci -d 14e4: -v > 01:00.0 Network controller: Broadcom Corporation BCM43225 802.11b/g/n > (rev 01) > Subsystem: Wistron NeWeb Corp. Device 04db > Flags: bus master, fast devsel, latency 0, IRQ 11 > Memory at dfe00000 (64-bit, non-prefetchable) [size=16K] > Capabilities: [40] Power Management version 3 > Capabilities: [58] Vendor Specific Information: Len=78 <?> > Capabilities: [48] 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-b1-ff-ff-29-00-1b > Capabilities: [16c] Power Budgeting <?> > > John Hi, Could you provide the output of "modinfo bcma | grep alias" as Rafał asked. The Debian kernel 3.2 contains some patch removing all PCI IDs expect 14e4:4331 from bcma, if this is still in your kernel that's the problem. If this is the case please try this: echo "14e4 4357" > /sys/bus/pci/drivers/bcma-pci-bridge/new_id Hauke -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
