Gordon Marler ??: > Thanks for those tips, George. I'll give those a try too. > <p> > Just a reminder, as discussed earlier in this thread, the thread title is > misleading - this is because scanpci in 2008.11 is showing an identifier > string of BCM4312, but the raw PCI ID is plainly a 14e4,<b>4315</b> chipset. > I guess that means I should log a defect that scanpci should show a string of > BCM4315. Or do I misunderstand the mapping between Broadcom device name > strings and PCI IDs? > It is not a scanpci defect, but something needs to clarify: broadcom wireless product name never match device ID, for example, BCM4306 product name match to device "14e4, 4320". BCM4309 product name match to device "14e4, 4324" BCM4321 product name match to device "14e4, 4328" and "14e4,432a" ?... BCM4312 product name match to device "14e4, 4315" ... NDIS page dosn't care broadcom product name, it uses device ID to identify actual BCM device, and, BCM product name is no use from driver's point of view. > <p> > Anyway, although the 14e4,4315 device is listed as supported by the HP > sp39243.exe driver listed on the OpenSolaris NDIS site for the 14e4,4312, > that driver has been superseded by the <a > href='http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?lang=en&cc=us&prodTypeId=15351&prodSeriesId=447687&swItem=ob-61972-1&mode=3'>sp39912.exe</a> > driver, which is version 7.00 E. That's the version I'm testing with now. > If you click on the "Revision History" tab of the driver link above, you'll > see there's even a newer version of the driver that that, from last month. > <p> > Good to know it, please keep post your test result. > I definitely had to disable NWAM and manually activate the wireless link with > dladm and ifconfig. Once done, the new driver from sp39912.exe runs the > 14e4,4315 chipset at much faster speeds than the driver from sp39243.exe. > And it doesn't hang - at least, not yet. > It seems to me nwam interact part needs to be improved. > <p> > The fact that 2008.11 doesn't create the /var/crash/... dir hierarchy when > using ZFS boot prevented me from getting crash dumps up until today. Just > fixed that and tested it, so if I get a crash again, I can at least provide > you with some hard evidence. Looking good so far though... > Yes, when no core dump was saved after a crash, you difinitely need to check with command #dumpadm.
- Michael
