Re: Problem with your tree
On Tuesday 06 March 2007 03:14, Larry Finger wrote: Michael, I decided to give the mb tree another go and pulled your latest (as of about 00:00 GMT on 06-03). When I boot, I get the following in dmesg: ssb: Sonics Silicon Backplane found on PCI device :01:00.0 ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x11, vendor 0x4243) ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0A, vendor 0x4243) ssb: Core 2 found: USB 1.1 Host (cc 0x817, rev 0x03, vendor 0x4243) ssb: Core 3 found: PCI-E (cc 0x820, rev 0x01, vendor 0x4243) ssb: Switching to ChipCommon core, index 0 ssb: Switching to PCI-E core, index 3 ssb: Switching to USB 1.1 Host core, index 2 === What's this?? Unable to handle kernel NULL pointer dereference at 02d0 RIP: [8812fcfd] :usbcore:usb_create_hcd+0x3b/0xe8 PGD 3e792067 PUD 3ed66067 PMD 0 Oops: 0002 [1] SMP CPU 0 Modules linked in: ide_cd ohci1394 bcm43xx_mac80211 firmware_class cdrom mac80211 ieee1394 forcedeth ohci_hcd cfg80211 ehci_hcd sdhci mmc_core i2c_nforce2 snd_hda_intel snd_hda_codec snd_pcm snd_timer usbcore snd soundcore ssb snd_page_alloc ext3 mbcache jbd edd sg fan sata_nv libata amd74xx thermal processor sd_mod scsi_mod ide_disk ide_core Pid: 1795, comm: modprobe Not tainted 2.6.21-rc1-mb-g034cca79-dirty #2 RIP: 0010:[8812fcfd] [8812fcfd] :usbcore:usb_create_hcd+0x3b/0xe8 RSP: :81003e039968 EFLAGS: 00010286 RAX: 81003d8d1178 RBX: 81003d8d1178 RCX: RDX: 81003dece498 RSI: 81003d8d1170 RDI: 81003d8d11f0 RBP: 81003e039988 R08: R09: 81003d8d1178 R10: 0001 R11: 810037f06730 R12: R13: 881fe340 R14: 0220 R15: 81003e4a7730 FS: 2af2e87af6f0() GS:80505000() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 02d0 CR3: 3d939000 CR4: 06e0 Process modprobe (pid: 1795, threadinfo 81003e038000, task 81003ef82100) Stack: fff4 81003eb03028 81003eb03028 81003e0399b8 881fcad3 88200e80 81003eb03028 88200eb8 81003e04de30 81003e0399d8 88106266 Call Trace: [881fcad3] :ohci_hcd:ssb_ohci_probe+0x58/0x105 [88106266] :ssb:ssb_device_probe+0x40/0x59 [8035314f] really_probe+0xce/0x162 [80353291] driver_probe_device+0xae/0xba [8035329d] __device_attach+0x0/0xb [803532a6] __device_attach+0x9/0xb [8035243e] bus_for_each_drv+0x47/0x7d [80353336] device_attach+0x6a/0x7e [80352389] bus_attach_device+0x24/0x4c [803510d7] device_add+0x459/0x630 [802ead5f] __spin_lock_init+0x31/0x52 [803512c7] device_register+0x19/0x1e [88105435] :ssb:ssb_attach_queued_buses+0x154/0x24b [88105fad] :ssb:ssb_bus_register+0x159/0x1b6 [8810605d] :ssb:ssb_bus_pcibus_register+0x1e/0x20 [88107a43] :ssb:ssb_pcihost_probe+0x7b/0xb0 [802f3221] pci_device_probe+0x4c/0x74 [8035314f] really_probe+0xce/0x162 [80353291] driver_probe_device+0xae/0xba [803533dd] __driver_attach+0x93/0xd3 [8035334a] __driver_attach+0x0/0xd3 [80352559] bus_for_each_dev+0x49/0x7a [80352f8d] driver_attach+0x1c/0x1e [803528d5] bus_add_driver+0x78/0x19c [80353662] driver_register+0x85/0x89 [802f3412] __pci_register_driver+0x95/0xd1 [8810791f] :ssb:ssb_pcihost_register+0x37/0x39 [880a801a] :bcm43xx_mac80211:bcm43xx_init+0x1a/0x50 [80254014] sys_init_module+0x15e9/0x1744 [802bcc73] dnotify_parent+0x28/0x73 [8823bc93] :mac80211:ieee80211_rx_irqsafe+0x0/0x6c [803d3f82] trace_hardirqs_on_thunk+0x35/0x37 [80209fae] system_call+0x7e/0x83 Code: 49 89 84 24 d0 02 00 00 e8 fa 5b 1b f8 fc 48 8d 7b 20 31 c0 RIP [8812fcfd] :usbcore:usb_create_hcd+0x3b/0xe8 RSP 81003e039968 CR2: 02d0 Is this problem related to the earlier discussion in the mailing list? If so, please ignore the noise. Please make sure you are using the very last version of my tree. I committed some USBhost related fixes yesterday. If you are using latest tree, well, find out what's going on. :) I don't have the hardware to test this. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problem with your tree
On Tuesday 06 March 2007 11:01, Michael Buesch wrote: On Tuesday 06 March 2007 03:14, Larry Finger wrote: Michael, I decided to give the mb tree another go and pulled your latest (as of about 00:00 GMT on 06-03). When I boot, I get the following in dmesg: ssb: Sonics Silicon Backplane found on PCI device :01:00.0 ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x11, vendor 0x4243) ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0A, vendor 0x4243) ssb: Core 2 found: USB 1.1 Host (cc 0x817, rev 0x03, vendor 0x4243) ssb: Core 3 found: PCI-E (cc 0x820, rev 0x01, vendor 0x4243) ssb: Switching to ChipCommon core, index 0 ssb: Switching to PCI-E core, index 3 ssb: Switching to USB 1.1 Host core, index 2 === What's this?? What's the device, btw? Most likely this is a ghost-core, which needs some blacklisting. Or is this some embedded device with an USB? Anyway, the ohci driver seems to need fixing (if you used latest version). -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
bcm43xx master mode works for me
I just gave this another try, after porting the fix for the beacon_control kfree bug which I'd found and debugged with Michael on IRC earlier (changeset 8ce88367b520c0fb303832026d5604a414e1259c in his tree) to the latest wireless-dev [1] and making hostapd compile, I have master mode working with bcm43xx. That means I can now start working on creating a driver_nl82011.c for hostapd and killing off the prism2 ioctls one by one :) Help is always welcome though. johannes [1] actually, that's not strictly true. my tree also contains these patches: fix-mac80211-Kconfig [was sent to akpm for the s390 problems] tasklet-free-debug.patch [kills scheduled tasklets in memory that is being freed] fix-scanf.patch [fixes scanf, unfortunately nobody replied to that...] export-device-rename.patch [gregkh has that] wiphy-rename.patch [posted earlier] delete-netlink-wext.patch [posted earlier] rework-kconfig [posted earlier] bluetape1.patch bluetape2.patch bluetape3.patch bluetape4.patch bluetape5.patch [Michael Wu's patch series] sysfs-to-debugfs.patch [debugfs #1] more-sysfs-to-debugfs.patch [debugfs #2] wiphy-private-id.patch [posted earlier] mac80211-netdev-stuff-to-debugfs.patch [debugfs #3] fix-header-bogosities.patch [posted recently] nl80211-new-commands.patch [work in progress] wpa.h.patch [posted recently] bcm43xx-fix.patch [the ported fix] hostapd-compile.patch [posted FYI] signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Pull the patch sent under heading [PATCH] bcm43xx: Fix typo in B5PHY init specifications
John W. Linville wrote: On Sun, Mar 04, 2007 at 11:13:31PM -0600, Larry Finger wrote: Please pull the patch referenced in the subject. It completely kills my BCM4306 with phy-revision == 1. Joe Jezak and I will have to sort this one out. Just to be clear, I interpret this to mean do not apply that patch. Pull is often used to mean take the patch and apply it as in git pull. Let me know if I'm interpreting you incorrectly. Sorry to mess up the terminology. It should be discarded, ignored, and trashed!! Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Broadcom BCM94311MCG
On Tue, 2007-03-06 at 09:54 +0100, Tobias Becker wrote: Hello, i have the broadcom bcm94311mcg chip and use opensuse 10.2. its possible to use our driver bcm43xx for my chipset??? As far as I know, 4311 is the best supported chip. Just make sure you are using the softmac driver (bcm43xx) and not the dscape driver (bcm43xx_d80211 or bcm43xx_mac80211), as the later doesn't work well yet. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problem with your tree
Michael Buesch wrote: Please make sure you are using the very last version of my tree. I committed some USBhost related fixes yesterday. If you are using latest tree, well, find out what's going on. :) I don't have the hardware to test this. The only things in your tree this morning that I didn't have were the correction to initb5, and the change in tasklet killing. I will debug this problem as soon as I have the time. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problem with your tree
On Tuesday 06 March 2007 22:53, Larry Finger wrote: Michael Buesch wrote: Please make sure you are using the very last version of my tree. I committed some USBhost related fixes yesterday. If you are using latest tree, well, find out what's going on. :) I don't have the hardware to test this. The only things in your tree this morning that I didn't have were the correction to initb5, and the change in tasklet killing. I will debug this problem as soon as I have the time. Ok, thanks. I think we need a blacklist or better whitelist in the ohci driver to not drive devices with unconnected cores. But it shouldn't crash. At least not this way. :) I don't have a running device with usbcore right now (working on it), so I can't test that. I wish broadcom wouldn't have so many chips with dangling cores and other stuff around. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problem with your tree
Michael Buesch wrote: On Tuesday 06 March 2007 22:53, Larry Finger wrote: Michael Buesch wrote: Please make sure you are using the very last version of my tree. I committed some USBhost related fixes yesterday. If you are using latest tree, well, find out what's going on. :) I don't have the hardware to test this. The only things in your tree this morning that I didn't have were the correction to initb5, and the change in tasklet killing. I will debug this problem as soon as I have the time. Ok, thanks. I think we need a blacklist or better whitelist in the ohci driver to not drive devices with unconnected cores. But it shouldn't crash. At least not this way. :) I don't have a running device with usbcore right now (working on it), so I can't test that. I wish broadcom wouldn't have so many chips with dangling cores and other stuff around. If an 0x817 core really is a USB 1.1 HOST, we do need some way to detect that we are dealing with a PCI device and ignore the USB cores. Is there such a flag/indicator already available? Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problem with your tree
On Tuesday 06 March 2007 23:21, Larry Finger wrote: Michael Buesch wrote: On Tuesday 06 March 2007 22:53, Larry Finger wrote: Michael Buesch wrote: Please make sure you are using the very last version of my tree. I committed some USBhost related fixes yesterday. If you are using latest tree, well, find out what's going on. :) I don't have the hardware to test this. The only things in your tree this morning that I didn't have were the correction to initb5, and the change in tasklet killing. I will debug this problem as soon as I have the time. Ok, thanks. I think we need a blacklist or better whitelist in the ohci driver to not drive devices with unconnected cores. But it shouldn't crash. At least not this way. :) I don't have a running device with usbcore right now (working on it), so I can't test that. I wish broadcom wouldn't have so many chips with dangling cores and other stuff around. If an 0x817 core really is a USB 1.1 HOST, we do need some way to detect that we are dealing with a PCI device and ignore the USB cores. Is there such a flag/indicator already available? Uhm, well. Yeah. For the first we could restrict it to embedded-only devices. And the rest, well. Probably there's some way to find out if the core works or not, too. I need to look through the register stuff again. But again, it shouldn't oops like yours at registering the hcd. That seems like a software bug. It may oops later with a buserror, sure. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
