8740w. Would somebody be willing to run Belarc and report?

Would a few 8740w owners be willing to run the Belarc diagnostic program, then report what their motherboard is numbered, and if they have dual core or quad core cpus?

(Belarc is available for free) Belarc Advisor 5.1k - CNET Download.com

I ran Belarc on my weirdly configured 8740w (4 memory slots with a dual core cpu) and it reported I have an "HP 1520KBC ver. 33.30" motherboard. I strongly suspect this is a quad-core board, and it might be my usb port conflicts are due to having a dual-core cpu in a quad core board! (eBay machine, so who knows?)

 

"Hewlett-Packard 1520 KBC Version 33.2C" (quad-core CPU, 4 RAM slots)

I find it interesting that my production model has a lower version # on its motherboard than your prototype does!

 

Mine was 1520 KBC Version 33.2D (quad core, delivered Feb 2011).

We need to see a dual core board result.

 

Thanks, to you both.

Can somebody with a dual core machine help settle this?

 

I can try... (i5-520M)

Board: Hewlett-Packard 1520 KBC Version 33.2F
Serial Number: CNU04614KX

 

Some more data would be useful--more board numbers and cpus. Googling, I discovered somebody with a 33.2D board (same numbers as Kinght427's) running a dual core.

Maybe the quad boards can run dual core cpus (vice-versa?). Has anybody reported trying combinations? I'm trying to get together with somebody who has offered to lend me a quad core, to experiment.

 

I don't know if anyone can do anything with a mobo serial number, but I wouldn't recommend posting it to a public forum.

 

Thanks, again, to those of you who contributed their information. I've finally settled this issue experimentally. I am typing this on this machine with a slightly used i7-720qm cpu installed. So, it is not exclusively a dual-core motherboard, nor is it exclusively a quad-core motherboard. It seems to run equally well, and equally problematically, with either flavor of cpu. It is, however, faster with the quad core.

The problem I have been having installing/running windows with the USB ports enabled in the bios setup persists. That hasn't changed. But the machine is stable and runs fine with either a dual i5-420m, or a quad i7-720qm. I'll have to continue to troubleshoot a solution to the USB port conflict, but I have solved the mystery of whether it is a dual or a quad machine.

It is either, and it is both.

 

Does it have only USB 2.0, or are 2 of the ports 3.0?

 

I might be wrong, but was it not perfectly possible, in principle, to run quad-core cpus even on the "dual-core" motherboard? As far as I can remember from one of the owners' threads, some have actually done this with the appropriate cooling in place...

 

Two, forward-right, are marked "SS".

 

Nazi technology

 

Those would be the 3.0 ports. Are you able to turn those off and leave the 2.0 on? I have no reason to believe this would help anything other than the fact the 3.0 aren't natively supported (or something like that).

 

BTW, did you install the usb3 drivers? They were known to cause problems (not in my case, but I got the HP late).

 

At startup, whenever the USB ports are enabled in the bios, the little twirly circle goes around for awhile, I get a message that Windows is installing drivers, then the little twirly quits twirling and the system is locked-up. Doesn't matter if I'm in safe mode, or whatever, the system locks.

As I said, it doesn't seem to be a fundamental hardware issue: Ubuntu/linux runs perfectly. A corrupt and creaky old installation of Win7 32 from another machine runs fine. But, in any clean installation of Win7, nothing works if the USB ports are enabled in the bios. Clean boot doesn't help; disabling everything in device manager doesn't help. If I have USB ports enabled, NOTHING seems to prevent MS/Windows from installing some driver that locks the system (late in the startup, and late in the Windows installation program--all behind a happy-face Welcome screen) According to Windows Reliability Monitor report, none of this ever happens. No report is generated; nothing logs.

Maddening.

After updating all the drivers, and re-enabling defaults in the bios (including the USB ports), Windows started, reported it was installing device drivers, then froze again. This time, I managed to click on the drivers message at the moment of the freeze. The message: "pci to pci bridge."

Suggestions?

[Edit/follow-up added on 6/11/12] Well, I finally fixed this problem computer. I disabled all of the ports except for the USBs. Then, I reinstalled the USB port drivers. The HP NEC 3.0 drivers seemed fine, but the Renesas drivers locked the computer up tight, and sent the computer into a hard shutdown and check-disk restart. Windows repaired some files, NEC USB 3.0 drivers installed, I enabled all of the ports--bios defaults--and this computer is finally behaving itself.

 

I have a dual-core 8740w, purchased (BTO) in Nov 2010. I have two memory slots on the motherboard. My result from Belarc is as follows:

Hope that helps. PM me if you need more info, as I don't always get around to checking all the threads I've posted in.

 

Interesting result: two owners have "1520 KBC Version 33.2D" boards with different memory slots, running different cpus--one dual-core, with two memory slots, and one of quad-core with four slots.

My board, a 1520 KBC Version 33.30 with four slots, ran either a quad or a dual core equally well. The USB port conflicts I experienced very likely had no relationship to the cpu question.

Thanks, again, to all of you who ran Belarc and reported.

 

But has it ever been established that there is a difference between dualcore and quadcore boards other than the available memory slots (and the cooling, but that is not onboard)?

 

Maybe the chipset is different? I know for some of the notebooks I've tested in the past, this has been the case. I forget what model chipset my notebook has.

boxman, thanks for following up on your fix. Too often on Internet forums we get the "unsolvable" issue where the original poster stops updating the thread and nobody knows whether it was solved.