Yes, I understand that some people have it working in their setups, and
I've seen a couple of people indicating they've had similar problems
as I do with respect to USB devices locking up the BIOS boot phase.
ASUS seems to have no very attentively monitored way to submit
technical bug reports about their BIOS (general technical support = useless
as far as I can tell). Their web forums are (to me) beyond uselessly
screwed up -- 99.9% of the time I get an error page whenever I try to
access their 'product support' forum pages more than a hand full of times:
Quote:
Due to vast number of connections online, the page that you requested cannot be displayed properly. Please re-connect using any of the following URL. Sorry for the inconvenience.
I didn't mean to imply these bugs were exclusicvely
P5K Deluxe + WiFi 0501 Beta BIOS version problems, it's just that
this is all that I've personally experienced / used -- it would surprise me
if they weren't also present in all other preceding versions of their BIOS.
My motherboard came with 0202 BIOS and that didn't support the Q6600 G0
stepping according to the ASUS CPU SUPPORT table and according to
an error message in the BIOS, so I had to reflash to *something* and,
it being a new motherboard model, I picked the latest assuming it'd
probably be the "latest and greatest" and in some way(s) better than
the preceding versions it was meant to replace. I know sometimes there
are new and regression bugs that may make an older BIOS a better choice,
but lacking any information to the contrary, 0501 Beta is the only one I've
tried so far.
Quote:
This is my current USB configuration, and it 'locks up' the BIOS POST
process 100% of the time whenever the switched USB chain is plugged in
while the BIOS POST is in control. I've never waited for more than a couple
of minutes to see if it'd eventually do something different, but to givel all
keyboard stimuli and available visual cues it seemed to just be locked up.
Motherboard USB Port A
-> SanDisk Corp. SDCZ2 Cruzer Mini Flash Drive (thin)
Motherboard USB Port B
*********** -> USB switch
****************** -> Keyspan USB 1.1 5-port HUB A -- AC powered and AC power connected.
********************* -> Link to Keyspan USB 1.1 5-port HUB B -- Physically Disconnected
********************* -> Microsoft Corp. Internet Keyboard Pro with built in 2 port USB hub (empty).
********************* -> Creative Technology, Ltd Fatality 1010 mouse
********************* -> DELL 2405 LCD Monitor with built in USB 1.x hub, and memory card reader.
*************************** -> Microsoft Corp. Wireless Intellimouse Explorer 2.0
*************************** -> Canon PIXMA IP 2000 printer
So that's one external hub branching out in "Y" parallel to two more
connected USB hubs. My 'full' configuration (involving the hub
I indicated as disconnected) would involve several other devices
and chained hubs, though it doesn't even take that to lock up the BIOS,
it crashes 100% with even the simple stripped down configuration.
I can hardly remove the built in hub/card reader in the keyboard and
the monitor, and of course I need the keyboard + monitor to boot, so,
other than having an extra mouse attached I'm pretty much down
to a very common sort of minimal setup already:
USB keyboard + 2 USB mice + card reader + printer + few incidental hubs.
EDIT: UPDATE: I tested various USB configurations for about an hour
and determined that the ASUS 0501 BETA BIOS locks up when
there's a mouse plugged in to one of the hub ports on the
DELL LCD 2405FPW's built in hub. When I remove a mouse from the DELL
hub port, the ASUS BIOS boots and stays functionally responsive. When
I attach peripherals OTHER THAN a mouse to the DELL LCD USB HUB
ports, everything works with no trouble from the ASUS BIOS -- I've attached
a Sandisk Cruzer USB Flash Drive, and a BELKIN USB Wireless NIC to the
DELL LCD USB HUB and those peripherals being attached there do not impair
the ASUS BIOS function.
I tested with three mice:
1) the Microsoft Wireless Intellimouse Explorer 2.0,
2) MEMOREX MX4210 optical wheel mouse.
3) Microsoft Basic Optical Mouse
and all three cause lock-ups of the ASUS BIOS when they're attached to
either of the two DELL USB ports.
When I attach them instead to OTHER USB HUB ports NOT connected
through the DELL LCD they work and do not interfere with the ASUS BIOS boot.
When I plug in one of these mice through the DELL LCD USB HUB AFTER
I'm ALREADY in the ASUS BIOS SETUP screen, I can navigate to the USB
screen in the BIOS setup and see that it indeed detected and is counting
the mouse in its peripheral list, so it is capable of functioning through
the DELL monitor USB HUB and with the ASUS BIOS, but the bug happens
during BIOS POS specifically.
When I plug in the USB stuff to the motherboard AFTER BIOS POST
is finished, the mice and anything else will work fine in LINUX even
through the DELL LCD USB HUB.
Quote:
This is very probably the exact error message I get from LINUX about
the BIOS BUG about memory reservation it happens before logging
is enabled so I have only a visual record of it but it's quite
familiar and now that I've had a chance to search for the exact text
I recognize it. I've seen similar issues with
other known buggy BIOSes in the past (e.g. VIA EPIA M), as have the
kernel authors which is undoubtedly why they put that specific check and
bug error message in the code.
PCI: BIOS Bug: MCFG area at e0000000 is not E820-reserved
EDIT: UPDATE: Confirmed.
Here are the actual captured LINIX KERNEL BIOS bug related
error messages; it looks like there's one bug with the BIOS
making a bad ACPI data table checksum, another bug with the
BIOS not indicating its reserving of a certain memory block,
and another which relates to CPU power management's
absence [which might be actually due to either the bad checksum or
the non-reserved memory table].
Quote:
PCI: BIOS Bug: MCFG area at e0000000 is not E820-reserved
PCI: Not using MMCONFIG.
PCI: Using configuration type 1
ACPI: Interpreter enabled
ACPI: (supports S0 S1 S3 S4 S5)
...
pnp: 00:0a: iomem range 0xfee00000-0xfee00fff could not be reserved
...
pnp: 00:0d: iomem range 0x0-0x9ffff could not be reserved
...
pnp: 00:0d: iomem range 0xe0000-0xfffff could not be reserved
pnp: 00:0d: iomem range 0x100000-0xcfffffff could not be reserved
...
ACPI Warning (tbutils-0158): Incorrect checksum in table [OEMB] - 7C, should be
7B [20070126]
ACPI: SSDT CFF8E0D0, 0190 (r1 AMI CPU1PM 1 INTL 20060113)
ACPI: SSDT CFF8E260, 0143 (r1 AMI CPU2PM 1 INTL 20060113)
ACPI: SSDT CFF8E3B0, 0143 (r1 AMI CPU3PM 1 INTL 20060113)
ACPI: SSDT CFF8E500, 0143 (r1 AMI CPU4PM 1 INTL 20060113)
hpet_resources: 0xfed00000 is busy
...
acpi-cpufreq: No P-States
cpufreq-core: initialization failed
EDIT: UPDATE: I got a chance to spend a few hours
researching how EIST works, reboot and go through the BIOS options
that might affect the CPU Power Management. It turns out that when
you set the CPU Multiplier in the BIOS setup away from AUTO to a given
number (e.g. X9) that causes the BIOS to delete the P-states in the ACPI
table corresponding to speed steps slower than the given speed.
That was unexpected (to me) since I'd assumed the BIOS would use
the manually set multiplier as the "normal" / "base" value (e.g. x9), but
still enable LOWER multipliers to be defined and used by the power
management (EIST/C1E/TM2) functions. Evidentally not.
The EIST/C1E/TM2 capabilities do work by changing the CPU
multiplier, so it's not unexpected that locking the CPU multiplier would
prevent the multiplier from changing in response to EIST/C1E; the only
unexpected part was the bit about it being a user set multiplier "lock"
that disabled the use of lower multipliers vs. it being just a specification
of the "desired maximum" multiplier. It doesn't necessarily make sense
in the BIOS for it to LET you change the CPU multiplier from AUTO
*and* have other distinctly usable options to enable/disable C1E etc.
but anyway now I understand what happened and have it working.
Anyway now that I changed the CPU multiplier to "AUTO" LINUX
is permitting two steps of power management for me:
* acpi-cpufreq: *P0: 2394 MHz, 88000 mW, 10 uS [1.15Vcore for my CPU]
* acpi-cpufreq: P1: 1596 MHz, 59048 mW, 10 uS [1.06Vcore for my CPU]
Where the P0 state = 266x9 and the P1 state is 266x6.
Presumably P1 would also be the speed and power/voltage that
is also used for TM2 and C1E, though I haven't tested that.
I'm still a little surprised that there aren't MORE EIST steps appearing
e.g. corresponding to each of the Q6600's possible CPU multipliers
of x9, x8, x7, x6, but I haven't seen any indication that that's actually
done in other peoples' BIOSes for the Q6600 so maybe that's "normal"
to just have the two speed steps (full and minumum frequency via
the CPU multiplier setting).
So now I'm getting happier since I have found a work-around for the
USB lock up bug, and also the EIST/C1E power management usage.
Unfortunately now it seems like I can't use the EIST power management
directly when I overclock the FSB a lot since it seems that it is not designed
to permit reducing the FSB AND the CPU multiplier AND the CPU voltage
when lower performance is acceptable, it only changes the CPU multiplier
and CPU Vcore. So maybe there is some utility I can find to change
FSB dynamically under LINUX/UNIX.
...
I think they must not make their BIOS authors actually test their releases
or use the products they apply to in 'real world' circumstances since
otherwise a lot of this stuff would NEVER make it to even a BETA
release (e.g. lockups due to USB, memory reservation errors,
broken ACPI, massively wrong indicated voltages / termperatures for several
other models I've read about etc. etc.).
Ah well I just wish there was an effective way to get more directly the
ear of the BIOS developers so we could get some of the long-absent
fixes and most desired features added in response to our feedback.
As it is it seems like we just wait and hope and maybe unplug our USB
hubs when we reboot.
Quote:
I'll do more USB bug testing to see if I can narrow down the cause(s) of the
problem to certain peripherals or configurations further. I've been busy
programming and doing system burn-in to reboot / test much so far.
DONE! See above.
Quote:
EDIT:
Oh, yeah, and neither the BIOS hardware monitor nor LINUX' sensors control
panel seems to be detecting the RPM of one of my two CPU fans. One is
showing up at the expected 1622 RPM on "FAN5" but "AUX FAN",
"CPU FAN", "CASE FAN" are all listed at 0 RPM and I think there may be
one or two fan connectors that actually exist on the motherboard that aren't
even mentioned in the BIOS health monitoring list or other programs I've seen.
I've got to track down what fan port the other fan is plugged into. I know
it is spinning since I've seen to that, but the absent or incorrect monitoring of
that fan port seems like a potential other BIOS bug to me so far.
UPDATE EDIT: Looks like the BIOS 0501BETA in the HARDWARE screen
monitors:
CPU FAN SPEED
CHASSIS FAN SPEED 1
CHASSIS FAN SPEED 2
CHASSIS FAN SPEED 3
...so it DOES NOT include either
CHASSIS FAN SPEED 4
or POWER FAN SPEED as it should do so since those are
available fan connectors on the motherboard.
Quote:
EDIT2:
Oh yeah another BIOS problem I noticed. If I went right into the BIOS
setup by hitting DEL or whatever then I could select EZ flash from the
BIOS tools option there in the BIOS setup screens. However
at that place it did not recognize / show any files from my SanDisk USB
flash disk which had the new BIOS file on it.
However if I did NOT enter BIOS SETUP and used the ALT-F2 or whatever
sequence to go from the BIOS POST TEST screen to the EZ-FLASH, THEN
it would list the files from my USB flash disk. I think they must not actually
initialize the USB ports including your USB flash disks until a later time
in the BIOS boot process so if you try to go to BIOS SETUP or EZ FLASH
before such time as it has registered your USB disks, you cannot seemingly
use EZ flash from them.
UPDATE: EDIT: It looks like that might have been a problem with
BIOS 0202 more so than 0501 BETA.
Now with 0501 BETA BIOS if you enable LEGACY DEVICE SUPPORT
in the BIOS SETUP, you can see your USB flash disk files from either way
of entering EZ flash at least when I've recently tested it using my USB
keyboard as the means of getting into the BIOS setup (whereas in the
past I had used a PS/2 keyboard, but hopefully that's irrelevant).
Surprisingly, however, If I DO NOT enable LEGACY DEVICE SUPPORT
in the BIOS SETUP, it would not 'see' my USB SANDISK CRUZER flash disks
in EZ FLASH at all. In this case if you go to EZ FLASH you get the
nice error message:
"There Are No Any Existing Drives!"
I'm not sure how a modern USB flash disk is a 'legacy'
device whereas a mouse and keyboard isn't but whatever.
So FWIW in case it's helpful to anyone, that's what I now know about
BIOS 0501 BETA.
Quote:
Originally Posted by
xgman
I had some of these sort of usb issues with earlier P5K dlx bioses. I don't think it has much to do with the bios version at all actually.
Quote:
Originally Posted by
safan80
no usb problems here I have two hubs, 2 mice, keyboard, usb drink cooler, SD/CF card reader, and an ipod. as for your ACPI troubles enable ACPI 2.0 in the power section of the bios. I get no such errors with several Linux install CDs. I don't have speedstep or C1e enabled. you might need to get a newer kernel and compile your kernel because it sounds to me like your running an old kernel.
Quote:
Originally Posted by
Leeghoofd
Flash only beta's at your own risk, and give feedback...listing all your hardware could be nice and not just say on your rig it sucks doesn't help others ...
There can be issues on some combination of hardware, that's why they are beta's and some don't even make it into a final release, some are even withdrawn hours after release as they seem to bork some mobo's,....
And due to the abundance of hardware floating around it's kinda hard to release one bios that supports all...
Also the rule of thumb is : If it ain't broke don't fix it !!! so only flash if you really need it !!
It's at your own risk to flash and use a beta, some are good, some suck , some kill boards, some make your rig fly... only way to find out is to give them a try or let others do it for you... but you know you are taking a risk !!! If it ian't good flash back to the workign one... and share ya findings with the engineers.... and us....
