Sony VPC-Z11 - Slow POST

Greetings,

I'm seeing a problem during boot-up on my Sony Z VPCZ11FHX/XQ.

The machine appears to take longer to complete the POST process than it should. In the following video, you can see that after the Intel Option ROM display, there is an extended time where the cursor blinks. While this happens, the HDD indicator light stays lit.

YouTube - Sony Z VPCZ11FHX/XQ - Slow POST

Unfortunately, I didn't shoot any video of this specific machine before this issue began but I did shoot one on an "eval" VPCZ112GX/S I had previously.

YouTube - Sony Z post time with RAID shown and hidden.

Questions:

1. Is anybody else seeing this behavior
2. Did it boot faster at some point? What did you do when it became slower?

To date, here is what I've done to troubleshoot the issue.

1. Deleted and recongifured the RAID Volume
2. Ran the system in JBOD
3. Reset BIOS to defaults
4. Removed the internal CMOS battery for several hours
5. Evaluated both clean and Sony recovery Windows 7 builds

And finally, here is how I'm running the machine:

1. Feature enabled BIOS (slow POST's happened before and after)
2. Disconnected internal BluRay (ran with and without)

 

I looked at your video it's very very slow post. I never get the same behavior like you. Did you try AHCI or IDE mode? Does it still get slow POST?

PS.Can you give the instruction of how to remove CMOS battery.

 

I did a few things with the system set to IDE when attempting a SECURE_ERASE, but I don't recall if it helped with the POST delay.

The CMOS battery is very accessible. Just remove the keyboard and disconnect the battery from the mainboard.

It's the black thing with "SUMITUBE" on it in the lower-left in this pic.


Be advised that doing this affected Windows Activation. Win7 said it wasn't genuine after the reset. I had to call MS to have it activated again.

 

Normal Post as factory default:

YouTube - Sony Z Sony VPCZ11X5E - factory default POST

No reconfigured RAID 0, no Windows clean/fresh install: all original.

 

Yep, mine is definitely messed up.

 

One does not have to modify anything on the VPCZ1 to get the blinking cursor delay between the BIOS screen and the Windows start screen. I just restored drive C: to the "original factory condition" (not so) using the VAIO Recovery Center. On my VPCZ118GX/S the cursor blinks 17 times before I see the Windows start screen.

I called Sony Technical Support. The person with whom I spoke at the "elevated level" acknowledged that after performing a drive C: or a complete system restore the notebook may take longer to boot but that Sony deems this to be normal behavior and that, therefore, no warranty service needed to be provided.

Since Sony did not provide a solution, I got an RMA. The notebook will be returned tomorrow.

 

Wow, that's some sh*t.

Where are you located?

 

Yepp, mine is like that as well. Slow, but nowhere as as slow as ZoinksS2k's post..
Vaio Restore from the original partition...

 

I'm really disappointed in Sony's response to Globalist. Unbelievable.

It is an issue, as you can see from my example. The machine boots incredibly fast after the cursor stops. Sony claiming it is normal is unacceptable. Restoring with the Sony media should return the machine to a pristine state. Period.

I'm traveling for the rest of the week, but will call Sony at some point to see if they give me the same line.

It almost has to be something with the partition setup and that can be replicated. I'll go as far as to order another machine to get to the bottom of the issue.

Really disappointing.

 

Just throwing an idea around: since it stays slow after restore it must have something to do with BIOS. The only thing I can think of is fingerprint data. Could you try clearing fingerprint data in BIOS and see if it helps any?

Edit: I know that pre-boot fingerprint authentication does not work in Z11, still it may "do something" in background if there is fingerprint data stored in BIOS data area by the UPEK software.

 

Just tried clearing the fingerprint data. No joy.

Thanks tho.

Can somebody with a normal install do some diskpart commands?

Here is mine:

PHP:

Copyright (C) 1999-2008 Microsoft Corporation.
On computer: ZOINKS-Z

DISKPART> list disk

  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
  Disk 0    Online          476 GB    50 GB
  Disk 1    No Media           0 B      0 B

DISKPART> select disk 0

Disk 0 is now the selected disk.

DISKPART> list partition

  Partition ###  Type              Size     Offset
  -------------  ----------------  -------  -------
  Partition 1    Primary            100 MB  1024 KB
  Partition 2    Primary             69 GB   101 MB
  Partition 0    Extended           407 GB    69 GB
  Partition 3    Logical            357 GB    69 GB

DISKPART> list volume

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0         System Rese  NTFS   Partition    100 MB  Healthy    System
  Volume 1     C                NTFS   Partition     69 GB  Healthy    Boot
  Volume 2     D   Storage      NTFS   Partition    357 GB  Healthy
  Volume 3     E                       Removable       0 B  No Media

 

here it is:

 

I don't know if what I'm saying is right in anyway, but here goes.

Have you tried clean installing any other OS other than Windows 7? Kinda curious considering W7 has that 100MB 'System Reserved' partition. I'm guessing you left that untouched when you were install and restoring your machine...?

SSD; you DID say that the machine, once it gets past the cursor, boots fast (ie, at its usual fast SSD speed). Maybe a specific part of the SSDs in RAID (where the boot-info is always stored) is giving way? Have you tried using just one SSD (that is, installing an OS on that one SSD) and tried booting off that alone?

Again, apologies if all the above sounds amateurish; SSDs are a new region of tech for me personally, but those are the only probably issues I can think of (apart from your 5th SSD setup and other BIOS tinkerings that you've been sharing with us here on NBR).
Regardless, good luck; hopefully you can get your machine up and running as usual.

 

here it is:

 

@ZoinksS2k: Just a thought, have you hacked your insyde BIOS? It might be something with the BIOS that introduces the extra delay...

 

I have feature enabled my BIOS, but it exhibited the issue before and after.

Looking at the diskparts, there isn't anything immediately telling like a weird offset.

 

My BIOS is hacked but boot time after Intel RAID Option is normal (ie. fast).

 

The cursor blinks 12 times until windows starts up. I'm not sure if this delay has increased since I fresh installed Windows 7, but it might have (didn't pay attention to that by now).

Non-modified BIOS.

Code:

DISKPART> list disk

  Datenträger ###  Status         Größe    Frei     Dyn  GPT
  ---------------  -------------  -------  -------  ---  ---
  Datenträger 0    Online          238 GB    13 GB
  Datenträger 1    Kein Medium        0 B      0 B
  Datenträger 2    Kein Medium        0 B      0 B

DISKPART> select disk 0

Datenträger 0 ist jetzt der gewählte Datenträger.

DISKPART> list partition

  Partition ###  Typ               Größe    Offset
  -------------  ----------------  -------  -------
  Partition 1    Primär             224 GB  1024 KB

DISKPART> list volume

  Volume ###  Bst  Bezeichnung  DS     Typ         Größe    Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0     G                       DVD-ROM         0 B  Kein Medi
  Volume 1     D                       DVD-ROM         0 B  Kein Medi
  Volume 2     C                NTFS   Partition    224 GB  Fehlerfre  System
  Volume 3     F                       Wechselmed      0 B  Kein Medi
  Volume 4     E                       Wechselmed      0 B  Kein Medi

DISKPART>

 

I have read that Windows Vista and 7 use a default offset of 1024 KB. However, after a VAIO Care recover of Drive C: the LIST PART of DRIVE 0 shows that the Recovery partition has a 1024 KB offset while Partition 1 (100 MB) and Partition 2 (348 GB) have an 8 GB offset.

Based on a Windows 7 default offset of 1024 KB, I would have expected Partition 1 to have an offset of 1024 KB and not 8 GB.

 

The first partition is the only one that counts. The 8GB offset for the second partition is due to the 8GB Recovery space.

 

I thought that Windows 7 was expecting a 1024 KB offset on the Primary partition rather than the Recovery Partition.

 

I get about 8 blinks, but I am only dual SSD-raid (128GB). My guess is it's legacy code in the intel option rom and/or bios waiting for "spin-up"

 

And it happens with stock and hacked bios. No difference.

 

Using Ratemodel's, er, model....

Partition 1
Size = 8GB
Offset = 1024

Partition 2
Size = 100MB
Offset = 8GB <-- due to the recovery partition

Partition 3
Size 169GB
Offset = 8GB + 100mb, only registers as 8GB

This is all normal.

 

I don't know whether that's a requirement or just a default, but I do know that Windows require partitions to be in a certain order:

- EFI or EISA partition, if any
- System partition, if separate from the Boot partition. Must be marked as Boot/Active.
- Boot partitions and other partitions.

(Note that Windows, contrary to any other OS and common logic, puts boot files on the system partition, and the system files, i.e. Windows, on the boot partitions.)

It becomes even more complicated if using GPT instead of MSDOS partition layout, but so far, I don't think any Windows OEM has started using GPT (only Macs).

Oh, and for compatibility with old systems, the system partition has to start within the first 1024(?) sectors. Which can affect you if you have a large EFI or EISA partition and try to install XP as a second OS on a newer machine. Then you may have to use BCDEdit to chainload the XP loader.

 

Somehow overlooked this response.

I tend to agree. I didn't really think it was an issue for quite a while, just the price paid for 4 hard drives. Some legacy timer element for drives to spin up.

Apparently, Sony did something to bypass this that isn't user repeatable.

I've got an Accusys 61010 RAID controller in my workstation and it's startup time is biblically long. Guess I built up a tolerance.

 

I've got that 100MB system partition, I don't have a startup cursor blinking problem, the screen blinks a couple of times trying to give me a seizure but that's about it. When I RAIDed X25-Ms, I don't think those have delays either:

Code:

Microsoft DiskPart version 6.1.7600
Copyright (C) 1999-2008 Microsoft Corporation.
On computer: XYZ

DISKPART> list disk

  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
  Disk 0    Online           74 GB      0 B
  Disk 1    No Media           0 B      0 B
  Disk 2    No Media           0 B      0 B
  Disk 3    No Media           0 B      0 B

DISKPART> select disk 0

Disk 0 is now the selected disk.

DISKPART> list partition

  Partition ###  Type              Size     Offset
  -------------  ----------------  -------  -------
  Partition 1    Primary            100 MB  1024 KB
  Partition 2    Primary             74 GB   101 MB

DISKPART> list volume

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0         System Rese  NTFS   Partition    100 MB  Healthy    System
  Volume 1     C                NTFS   Partition     74 GB  Healthy    Boot
  Volume 2     F                       Removable       0 B  No Media
  Volume 3     E                       Removable       0 B  No Media
  Volume 4     D                       Removable       0 B  No Media

 

Part of the slowdown might not be due to waiting for spin-up, but actually searching for the RAID metadata.

The RAID marker is placed near the end of the disk -- the default position for ICH10 software raids is 2115 sectors from the end of the disk, but it varies depending on the RAID.
But, if you have allocated all of the disk, the RAID marker has to be moved towards the end.
With IBM/MSDOS partition tables there's no way to record just where to -- only the start of a partition is recorded. So when you boot, the RAID assembly routine will start at the "preferred sector", and then read and examine one and one block towards the end until it either finds a RAID marker or the disk runs out.

This approach means there are different impacts on boot scan time based on the alignment of the partitions.

To reduce this, try:
1: Zero out the last ~2500 sectors of the disk. (This also gets rid of old leftover RAID markers, which may confuse the post-BIOS scan)
2: Write new RAID markers.
3: Leave the last ~2500 sectors of the disk unassigned.

Also, make sure that ALL of your partitions end on sector boundaries, which increases the speed of which partitions can be scanned (a logical sector will never span two physical sectors). I.e. allocate them by specifying sectors and not megabytes (unless your partitioning software automatically moves to the nearest sector boundary instead of just translating).

 

Here is mine:

 

I think the issue has to be something like you mentioned, Arth1.

I was dorking around this morning and, as you'd think, disabling the IDE controller altogether or setting it to AHCI removes the delay.

Now, how would one re-write the RAID markers? Use DMRAID or an equivalent utility?

I'll give it a go this weekend. Even though I've had this issue for a long time, now knowing it isn't normal has set off my irritation-nerve. This has to get resolved.

 

I would be willing to purchase the necessary software licenses and put the time and effort required to get a "20-second boot" from the VPCZ1 if I knew what to do. I appreciate what you are doing.

 

Not sure what you mean.

I if I don't find information on the signature or "disk marker" mentioned above, I'd go as far as purchasing another Z1 to evaluate/analyze and return it. Don't think this will be necessary at this point, but who knows.

 

I meant that all the effort that you have been putting on resolving this issue is valuable to VPCZ1 owners and that I appreciate it.

 

Can anybody running Loonix or who has access to a Linux boot disk run this command and dump the info?

You should also be able to boot normally without the "blinky cursor" delay.

dmraid -n

 

Thank me when (if) the issue is resolved.

I think this is fixable, but I've said that before (Optimus).

 

Code:

mdadm --zero-superblock --force /dev/sda

or

Code:

dmraid -E -r /dev/sda

or both.
(repeat for sdb, sdc and sdd)

But if you really want to be sure that all raid markers are gone no matter where they are located, you need to zonk (or, in your case, zoink) the entire end of the drive. Something like this would do it:

Code:

fdisk -l /dev/sda \
| awk '(/cylinders$/) \
{ print "dd if=/dev/zero of=/dev/sda seek="$5-2500}' \
| sh

 

Just for curiosity: what is stored within this metadata or markers, why can't this information be stored within the RAID controller so we wouldn't have this mess and why for gods sake is it stored somewhere on the disk and not at a better to find location (like at the end of the disk).

 

What's stored in the superblock is data telling of things like
- the raid type (like Intel software raid, adaptec rocketraid or other)
- a unique identifier for the raid it belongs to
- the raid level (like RAID5)
- the status of the partition (clean, dirty, removed, failed, spare)
- the size of the part that belongs to this RAID (which isn't always the entire disk)

It's not stored in the controller because many of the controllers don't have persistent storage (like the intel software raid controller in the Z), but more importantly because the purpose of a RAID (except RAID 0) is to be resilient. If the controller dies, the RAID should still survive.

Because there are many different RAID types, and a disk can belong to more than one RAID, the marker is stored in different places. To make it even more complicated, it can (for some RAID types) be stored inside a partition too, not just a disk. (Which is why Intel renamed their RAID to "matrix" -- you can do things like have RAID 0 and 1 at the same time with just two drives.) So there can be more than one marker.

The markers are near the end of the disk (or partition), but for speed, they should be on a multiple of the native sector size, so you'll lose a minimum of the difference between the sector size and block size.
There's usually a default location for them, but that's no guarantee.

 

Looks like this may be a Windows thing.

Can somebody run, from an elevated CMD prompt, bcdedit

Should look something like this (from my workstation, not Sony):

Once again, only post this information if your system boots without the "blinky cursor" issue.

My system posts normally until I install windows. After the first reboot on a fresh install, the extended-scanning problem starts.

I'm also interested why issue-free people who dumped their volume information all have the Sony Recovery partition.

 

Thanks for the explanation (even though I still think the way it is implemented is not an example of design quality).

 

Using the windows boot loader I have a delay of 12 blinks (not as horrid as yours, but some delay after all).
Using GRUB there is no delay at all, Windows boots immediately.

If you want to give it a try you can use Super Grub Disk (just use UNetBootIn to get it on a stick) and load you Windows using

Code:

root (hd1,0)
chainloader +1
boot

 

Could this be due to the clean install?
And that sony put something in there that is removed with a clean install?

 

Yes. Trying to figure out what that is specifically.

I'm going to pause shortly for family run day, but will restart soon

 

These clean installs can have more negative effects than one might think. I had an Asus Eee pc that got 11 hours of battery life. After doing a clean install I could only get 8, even after installing all the drivers.
Putting back everything to normal using the OS recovery disc it jumped back to 11.
So manufacturers dont seem to add ALL the files and drivers for download, some of these are well hidden in the recovery partition/disc and makes a big diff.

 

This issue occurs if you use the Sony Recovery Media to rebuild as well.

I'm throwing down a copy of SuperOS 9.1 currently

 

No. I did not do a clean install on my machine, and I am up to 22 blinks, though I recall it was much less when I first received the machine. I have installed a bunch of software as I use the machine for my work, however. I guess I'm so used to the Windows boot process slowing down that I never noticed it until I saw this thread.

-Peter

 

Did you change any settings with the RAID volume?

 

Did you ever perform a restore from the system partition or the recovery disks?

 

No on both counts. The only thing I did was uninstall some of the bloatware, then install my own software along with Windows updates.

-Peter

 

Hrm, you seem to be the exception.

I'm not having much luck so far and I got sidetracked installing Ubuntu during my hobby time.

I'll continue to work on it. I think replacing the Windows bootloader might help, but I'd rather figure out what the heck Sony does to the machines during the factory build.