PhatHack
The Hacking Hoedown => PhatBox Hacking => Topic started by: chico on December 31, 2007, 07:34:57 pm
-
I've been working with VorTechS on creating a new DMS with the PhatHack Tools (v 2.11) , but due to the myriad issues I've run into I thought a post was warranted. Keep in mind that I'm creating a new DMS to have on hand in addition to the original 20 GB DMS that came with my Phatbox, so I do have a working DMS. I've already hacked my phatbox using the PhatHack tools. That went quite smoothly. I'm running the x86 environment of Windows Vista on my main PC, and I have an older, much slower, PC running Windows XP. Initially I had a problem with Vista even recognizing the new drive (http://www.newegg.com/Product/Product.aspx?Item=N82E16822136130) as a USB device. I've installed a hotfix for Vista, and it cleared that problem up. I have noticed, however, that it still takes Vista much longer to recognize the drives on the DMS after I've created a new DMS with the PhatHack tools. For comparison, it takes XP about 30 seconds on my old computer to recognize the drives and it takes Vista about 20-30 minutes to do the same. Is that a function of the 111 GB FAT32 partition that houses the PHTDATA drive? If so, how do I address that?
The other main issue I've had is that, upon recognizing the newly created DMS, PMM 3.92 and PMM 1.87 both say that there is no headunit selected for the DMS. The headunit in my car is the VW Premium VI headunit, and I've created the new DMS with the VW 7.02 firmware, which is what is on my original DMS. I have looked at the CurrentSetup.xml (I think that's the correct file name, but I'm at work and can't check) from my original DMS and noticed that there is a field that specifically lists the headunit. I've added that to the CurrentSetup.xml file on the new DMS. Upon doing so, PMM 1.87 seems to recognize the DMS properly...for the most part. However, I have gotten "can't read CurrentSetup.xml" and "can't read WelcomeSoundFile.txt" at different times with PMM 3.92. That behavior is consistent regardless of the Windows version. Until I have a DMS that works properly with PMM 3.92 in Vista, this project won't be complete.
Any help you can provide for any of these issues is greatly appreciated. Thanks in advance.
-
In short, vista sucks... why must people continue to insist upon using it?
The CurrentSetup.xml thing must just be because vortech's tool didn't put the setting there when it loaded the firmware. You could try loading the firmware again in PMM and it would fix it, if by some miracle PhatNoise's firmware server were online...
-
In short, vista sucks... why must people continue to insist upon using it?
That's not a valid answer. :) As more and more people start moving away from XP, whether to Vista or the next version of Wndows, the hacked DMS will need to keep working if they're going to be worth anything. Ignoring a problem isn't the same as solving it.
The CurrentSetup.xml thing must just be because vortech's tool didn't put the setting there when it loaded the firmware. You could try loading the firmware again in PMM and it would fix it, if by some miracle PhatNoise's firmware server were online...
I've tried uploading the firmware through PMM, but as you've alluded to, Phatnoise's servers are rarely up (and weren't over the weekend). I think I'll try running the older versions of the hack tools that are posted in the Windows based DMS thread.
-
Okay, now I've run into a larger, much more significant problem than any I've had before. I tried to use the command prompt method with newdms.bat to try to get the DMS made that way. Now the partitions on the disk itself are bad. I've tried to use partition magic in Windows XP to delete the partitions to start over with the drive. However, partition magic gives me the error "Init failed: Error 100 Partition table is bad". Can this be fixed? If so, how? Have I permanently damaged the drive?
-
I would agrtee that it is not a valid answer if there were actually any advantages to Vista. Vista is just XP with more bloat. There is not software or hardware that requires vista.
Can't windows disk management remove your partitions? Worst case, you can just overwrite your partition tables with zeros. (dd zeros to first 512 bytes of drive) As long as it doesn't say you have bad sectors I wouldn't worry about it too much ;) ... None of the hack tools modify that xml file besides possibly VorTechS's windows tool. Your best bet on that is probably just editing it yourself as you have in the past. The errors reading could be Vista being Vista, or it could be bad sectors... like I said, see if it works well on XP.
-
I got the problem with the drive fixed by using some utilities I downloaded from Western Digital. The current plan of attack is to see if I can get the DMS working in XP and go from there. I've used the backup tools to make a copy of the PHTSYS files from my original, working DMS. I'm planning on just creating the PHTSYS and PHTDTA partitions on the new drive and copying the PHTSYS files from the original DMS to the new one. Is there any reason that that wouldn't be a good idea?
-
Okay. That still didn't work, though PMM 1.87 is recognizing it as a valid DMS with the correct firmware now. I ran DMS doctor, and it failed the systems files check and the profile & playlists check. The error message I got for the system files check was 'Could not find system file p:\<!DOCTYPE HTML PUBLIC "-' where "p" is the drive letter for the PHTSYS partition. I just got a 'No M3U Playlists Found' error for the profile & playlists check, which is not terribly surprising since I haven't actually transferred any music to the DMS.
I've run across some posts where it is recommended to use the "genesis method" as the last resort. However, the wiki page strongly advises against using that method anymore. Any thoughts or suggestions on any of this stuff is greatly appreciated. Thanks.
-
Ignore the system files check in DMS doctor; it's useless (see http://forum.phathack.com/index.php/topic,989.0.html)
-
CurrentSetup.xml is required by PMM for some stupid reason and it's a mirror image of the firmware XML fragment taken from what used to be firmware.xml on the PhatNoise site. Unfortunately before the site went down we didn't think to take a backup of this file so the file that the tools generate is from our own version of the file which does not mirror the same format.
I do have some original files that I could use to work from, but it's going to take time to modify the existing XML file into the same format which I'll do once I've dealt with other things and then hopefully PMM will behave itself a bit better afterwards.
-
I'm planning on just creating the PHTSYS and PHTDTA partitions on the new drive and copying the PHTSYS files from the original DMS to the new one. Is there any reason that that wouldn't be a good idea?
That should be fine, so long as the drive is <= 127GB -- but sometimes the firmware loader has issues loading the kernel if it's not at the beginning of the drive. Best bet would be to back up your old partitions then copy linux, linux.sig, ramdisk, and ramdisk.sig FIRST... then copy over the rest of the files.
-
Thanks for all the help guys. I tried the wholesale copying of my old PHTSYS partition to the new one last night and that still didn't work. I'll try copying the 4 files first and then the rest. I'll also try it with the "new" and old versions of CurrentSetup.xml.
-
Okay, so I've tried copying just the first 4 files and then the rest. I then opened PMM 1.87 and ejected the DMS so that PMM would create the default playlists. When I tried the DMS in my car, I got the "no CD" error message on the headunit. Should I try a different version of PMM to generate the default playlists? The only other version of PMM I have is 3.92 which has its own set of issues with a hacked DMS. Is there a PMM 3.xx version that doesn't cause problems with a hacked DMS?
-
You know the more I read back on this post, bearing in mind other posts elsewhere - I'm beginning to think this drive you are using is duff. For starters, IIRC you couldn't get Vista to recognise the drive without drivers - which is just stupid as I think I mentioned at the time. Drives shouldn't require drivers irrelevant of manufacturer or O/S.
I think you should give up with this one and try another drive.....
-
Vista recognized the drive and installed the drivers. It's just that it takes a while for the partitioned drives to show up in Windows Explorer. Maybe that's the same thing though. If that's the case, I'll just contact WD and get a replacement.
-
I disassembled the DMS cartridge and put the original drive back in it. Everything seemed to be run fine in Windows with it, so I don't think that there's a problem with the drive to pin adapter in the cartridge. Windows XP also identifies the DMS with no problem (as does PMM 1.87 in XP, though PMM 3.92 does not). I used the 'newdms.bat' method to create the DMS partitions and manually downloaded and installed the firmware files from the wiki. I installed the 4 files first and then the rest. I then added my old CurrentSetup.xml file, as there was none in the PHTSYS partition at that point. I opened PMM 1.87 to create the default playlists and ejected the DMS. I put the DMS in the Phatbox and still get the No CD error message. The green light comes on for a bit, goes off, blinks twice, blinks again once after a pause and the phatbox shuts off. I don't know if that helps or not.
With all that I've tried so far, is there anything you can think of that I haven't done right? If not, it looks like the time has come to contact WD and get a replacement drive. It would seem odd that the drive is the problem though since it seems to work fine everywhere except in the phatbox.
I do think that before I contact WD about a new drive, I'll put the original 10 GB drive that came in the cartridge back in and try to create a new DMS with it to see if that works. That would rule out there being errors in the VW 7.02 firmware files. I guess that brings up another good question. Has anyone recently made a new DMS with the VW 7.02 firmware that worked? If those files are corrupt, is it possible to roll my firmware back to VW 7.0? What are the disadvantages of 7.0 vs 7.02?
Sorry for the long post and scatterbrain nature of it. I'm just trying to make sure I have everything covered before getting a different drive.
-
DO NOT RUN DMS HACK SCRIPTS ON YOUR ORIGINAL DMS, this is A VERY BAD IDEA!!!!!
you'll ruin it. it will never be stock again if you dont do exactly the right things and if your computer doesn't behave exactly as the scripts expect.
you've been warned
-
Sorry for the confusion on that. The 10 GB hard drive is the original drive from the DMS I'm hacking. It is not the original drive from my phatbox. That one is a 20 GB drive that is still in the DMS cartridge. I won't be messing with the 20 GB drive.
-
After further testing, I am 90+% sure that the problem is with the VW 7.02 firmware files. I made a new DMS with the 10 GB drive and it didn't work. I opened both DMS cartridges and swapped in the hard drive pin adapter from the working cartridge. After ruling out the 120 GB drive as being the problem (or at least the sole problem) with the 10 GB drive and ruling out the pin adapter as the problem, the only logical conclusion is that the problem lies in the file system itself. I also ran the hack procedure again with my original 20 GB DMS and got the message that the box was already hacked, so I've ruled out that problem as well.
Has anyone actually created a VW 7.02 DMS successfully since the Phatbox firmware servers have been down? It seems that I sure can't. I have contacted Phatnoise about getting the 7.02 firmware files, but I don't expect a response any time soon from them.
Is it possible to roll back the firmware to VW 7.0? If so, what problems were fixed with the 7.02 firmware?
-
the only way to know if you've really hacked the box is to look at the log files and make sure its properly applied all the hacks. frequently problems pop up where the phtsys data is out of whack and wont boot... you may have a weird situation like that. you should be able to get prior version of the software from phatnoise or downloads.phathack.com
-
I sent the log files to VorTechS when I initially did the hack, and he confirmed that the hack was successful. If the DMS thinks the box is hacked when it really isn't, is there a way to force the hack to run again or is it a matter of running the hack procedure a number of times until it works?
-
I just ran the hack procedure again. Here's the contents of the bootload log:
BOOT0-0: OK
BOOT0-1: OK
BOOT0: Successful
BOOT9-X: Successful
BOOTB-X: Successful
BOOTF-X: Successful
BOOT*: Successful
Here's the contents of the patch log:
Verifying patch progress
This system is already patched
: No such file or directory
PhatPatch v0.8 - original code by bushing, additional patches by sbingner
Finding patch offsets:
Verified standard patch offsets
Verifying:
Patch 1 @ 0bb8: make drive signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00 Actual: 0000 1a00
Verified!
Patch 2 @ 0bec: make rc.sh signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00 Actual: 0000 1a00
Verified!
Patch 3 @ 0c20: make phatd signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00 Actual: 0000 1a00
Verified!
Patch 4 @ 0c54: make linux signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00 Actual: 0000 1a00
Verified!
Patch 5 @ 0354: make ramdisk invalid signature return 0 instead of 0xFFFFFFFF: [movlne r0, 0xFFFFFFFF -> movlne r0, #0]
Expected: 0000 13a0 Actual: 0000 13a0
Verified!
Patch 6 @ 0c80: make ramdisk signature check verify 0 instead of 1: [cmp r0, #1 -> cmp r0, #0]
Expected: 0000 e350 Actual: 0000 e350
Verified!
Patch 7 @ 0358: make ramdisk valid signature return 0 instead of 1: [moveq r0, #1 -> moveq r0, #0]
Expected: 0000 03a0 Actual: 0000 03a0
Verified!
Patch 8 @ 0330: don't try to read ramdisk.sig (boot without any .sig files): [bl sector_read_suzy -> bl PC+1]
Expected: 0000 eb00 Actual: 0000 eb00
Verified!
Patch 9 @ 02c0: don't try to read linux.sig (boot without any .sig files): [bl sector_read_suzy -> bl PC+1]
Expected: 0000 eb00 Actual: 0000 eb00
Verified!
PhatPatch v0.8 - original code by bushing, additional patches by sbingner
Finding patch offsets:
Verified standard patch offsets
first 2 words of flash=c102 0025
testing offsets 0x555 and 0x2aa
writing auto-id command (AA, 55, 90)
Flash chip reports manufacturer id=0001, device id=22bf
offsets 0x555 and 0x2aa verified
Resetting flash.
Testing patch locations:
Patch 1 @ 0bb8: make drive signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0033 1a00 Actual: 0000 1a00
Detected patch 1 already applied
Patch 2 @ 0bec: make rc.sh signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0026 1a00 Actual: 0000 1a00
Detected patch 2 already applied
Patch 3 @ 0c20: make phatd signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0019 1a00 Actual: 0000 1a00
Detected patch 3 already applied
Patch 4 @ 0c54: make linux signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 000c 1a00 Actual: 0000 1a00
Detected patch 4 already applied
Patch 5 @ 0354: make ramdisk invalid signature return 0 instead of 0xFFFFFFFF: [movlne r0, 0xFFFFFFFF -> movlne r0, #0]
Expected: 0000 13e0 Actual: 0000 13a0
Detected patch 5 already applied
Patch 6 @ 0c80: make ramdisk signature check verify 0 instead of 1: [cmp r0, #1 -> cmp r0, #0]
Expected: 0001 e350 Actual: 0000 e350
Detected patch 6 already applied
Patch 7 @ 0358: make ramdisk valid signature return 0 instead of 1: [moveq r0, #1 -> moveq r0, #0]
Expected: 0001 03a0 Actual: 0000 03a0
Detected patch 7 already applied
Patch 8 @ 0330: don't try to read ramdisk.sig (boot without any .sig files): [bl sector_read_suzy -> bl PC+1]
Expected: 02db eb00 Actual: 0000 eb00
Detected patch 8 already applied
Patch 9 @ 02c0: don't try to read linux.sig (boot without any .sig files): [bl sector_read_suzy -> bl PC+1]
Expected: 02f7 eb00 Actual: 0000 eb00
Detected patch 9 already applied
: No such file or directory
PhatPatch v0.8 - original code by bushing, additional patches by sbingner
Finding patch offsets:
Verified standard patch offsets
Verifying:
Patch 1 @ 0bb8: make drive signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00 Actual: 0000 1a00
Verified!
Patch 2 @ 0bec: make rc.sh signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00 Actual: 0000 1a00
Verified!
Patch 3 @ 0c20: make phatd signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00 Actual: 0000 1a00
Verified!
Patch 4 @ 0c54: make linux signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00 Actual: 0000 1a00
Verified!
Patch 5 @ 0354: make ramdisk invalid signature return 0 instead of 0xFFFFFFFF: [movlne r0, 0xFFFFFFFF -> movlne r0, #0]
Expected: 0000 13a0 Actual: 0000 13a0
Verified!
Patch 6 @ 0c80: make ramdisk signature check verify 0 instead of 1: [cmp r0, #1 -> cmp r0, #0]
Expected: 0000 e350 Actual: 0000 e350
Verified!
Patch 7 @ 0358: make ramdisk valid signature return 0 instead of 1: [moveq r0, #1 -> moveq r0, #0]
Expected: 0000 03a0 Actual: 0000 03a0
Verified!
Patch 8 @ 0330: don't try to read ramdisk.sig (boot without any .sig files): [bl sector_read_suzy -> bl PC+1]
Expected: 0000 eb00 Actual: 0000 eb00
Verified!
Patch 9 @ 02c0: don't try to read linux.sig (boot without any .sig files): [bl sector_read_suzy -> bl PC+1]
Expected: 0000 eb00 Actual: 0000 eb00
Verified!
PhatPatch v0.8 - original code by bushing, additional patches by sbingner
Finding patch offsets:
Verified standard patch offsets
first 2 words of flash=c102 0025
testing offsets 0x555 and 0x2aa
writing auto-id command (AA, 55, 90)
Flash chip reports manufacturer id=0001, device id=22bf
offsets 0x555 and 0x2aa verified
Resetting flash.
Testing patch locations:
Patch 1 @ 0bb8: make drive signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0033 1a00 Actual: 0000 1a00
Detected patch 1 already applied
Patch 2 @ 0bec: make rc.sh signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0026 1a00 Actual: 0000 1a00
Detected patch 2 already applied
Patch 3 @ 0c20: make phatd signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0019 1a00 Actual: 0000 1a00
Detected patch 3 already applied
Patch 4 @ 0c54: make linux signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 000c 1a00 Actual: 0000 1a00
Detected patch 4 already applied
Patch 5 @ 0354: make ramdisk invalid signature return 0 instead of 0xFFFFFFFF: [movlne r0, 0xFFFFFFFF -> movlne r0, #0]
Expected: 0000 13e0 Actual: 0000 13a0
Detected patch 5 already applied
Patch 6 @ 0c80: make ramdisk signature check verify 0 instead of 1: [cmp r0, #1 -> cmp r0, #0]
Expected: 0001 e350 Actual: 0000 e350
Detected patch 6 already applied
Patch 7 @ 0358: make ramdisk valid signature return 0 instead of 1: [moveq r0, #1 -> moveq r0, #0]
Expected: 0001 03a0 Actual: 0000 03a0
Detected patch 7 already applied
Patch 8 @ 0330: don't try to read ramdisk.sig (boot without any .sig files): [bl sector_read_suzy -> bl PC+1]
Expected: 02db eb00 Actual: 0000 eb00
Detected patch 8 already applied
Patch 9 @ 02c0: don't try to read linux.sig (boot without any .sig files): [bl sector_read_suzy -> bl PC+1]
Expected: 02f7 eb00 Actual: 0000 eb00
Detected patch 9 already applied
Is the box hacked or not? Where do I go from here?
-
The hack is applied. The logs shows the first time, it was applied and one the second execution its telling you the each of hacks in the process was already applied.
-
That's what I thought. Any ideas on how to get a hacked DMS to actually work? The original runs just fine, but I get the CD-X No CD error every time I try a hacked cartridge. Should I try reflashing the phatbox with the firmware or would that be a bad idea?
-
Something I just thought of that might help...or not. I still have the corrupt ramdisk.sig file on the original DMS that I used to hack the box. If I restore the original ramdisk.sig file and boot the phatbox with the original DMS, should the box recognize a hacked DMS after that? At this point it seems like there's one little, obscure thing I'm missing that's making the new DMS not work.
-
Your problem will be with the NEW DMS.... nothing you do with the old dms matters now. What your problem may be, I don't know. As long as it's properly partitioned and formatted it should work fine. I have heard reports of some people not being able to get certain drives to work at all, but I don't know why that would have been. Do you have another drive to try?
-
I started with the 120 GB WD drive. After having the problems I've had, I switched to the 10 GB Toshiba drive that originally came in that DMS cartridge (while not messing with the original 20 GB Toshiba drive in my original DMS), along with working in XP only and not Vista. Since I can't get an original Toshiba drive to work, it would seem that the hard drive isn't the problem...or at least isn't the only problem. Would reflashing the box with the VW 7.02 firmware be a good idea?
I did accidentally flash the box with the firmware because I forgot to remove the forceupdate file when I created a new DMS. In the hacking procedure it says to remove the forceupdate and forceupdate.settings files (or something close to that anyway). I noticed that there isn't a forceupdate settings file in the firmware files. Is that a problem?
-
That's not a problem... just make sure you let it COMPLETE the firmware update ;) --- you can reflash it if you like, it won't hurt.
Do you get a blink code with the new drive? Have you tried creating a bootload.log file on it? Do you have MUSIC on the new DMS? Have you tried adding debug rc.sh files?
-
With the new drive, the green light blinks once, there's a pause, it blinks twice, there's another pause, it blinks again and the phatbox shuts off. I'll try doing the firmware reflash tonight to see if that fixes things. I've looked at the bootload.log file after my latests attempt to hack the box (where it told me that the box had already been hacked) and all the boot checks were successful.
I hadn't put any music on the DMS at all in my earlier attempts, but last night I went through the DMS creation process again with the 10 GB drive and put some music on it. I haven't had time to test that out yet though. I was expecting to get the "corrupt track" error without music.
This is the first I've heard of a debug rc.sh file. I will look into that if the test tonight is unsuccessful.
Thanks again for the help.
-
If you have no music on it it will say no disc or no cd etc... it's hard to have a track be corrupt when it doesn't exist ;)
-
Well, between reflashing the phatbox with the firmware and actually putting music on the drive I was able to get the 10 GB hard drive to work. When I swapped the 120 GB drive into the DMS and set it up, it didn't work. When I put the cartridge in the phatbox, the green light blinked five times and then three times and then the box shut off. I got the CD-X No Magazine error on the headunit. It appears that the blink sequence indicates that there was a write error and then an error communicating with the IDE adapter. Since the IDE adapter worked just fine with the 10 GB drive, is it safe to assume I need to contact Western Digital at this point to get a new drive?
Thanks again everybody for your help. I can finally see some light at the end of the tunnel.
-
Actually 5 isn't exactly unable to write... it's more unable to seek or something... essentially it tried to read a sector and the drive didn't accept the command to read that sector for some reason. I doubt you have a hardware issue with the actual HDD, or it wouldn't work in windows either. Try formatting your PHTSYS, and loading up the files in a specific order - if you tell the Windows Patch Tool to create a new DMS for you, it should put it on properly... otherwise you can copy up 1. linux 2. linux.sig 3. ramdisk 4. ramdisk.sig 5. the rest of the contents of PHTSYS
-
Yup, the Windows hack tool loads the files up in that specific order after partitioning the disk.
Perhaps there's something I need to change in the formatting to mark bad blocks?
-
Okay. Well, I'll try things again tonight with it to see how it goes. That it takes Vista up to 30 minutes to recognize the partitions on the WD drive makes me think that the drive isn't good though either. I don't have that problem in Vista with either of the other drives I've used.
Something else I thought of this morning is that I created the DMS and then deleted the files in the PHTSYS partition. I then copied the files from the PHTSYS partition of my original DMS onto that partition. If I remember correctly, I think that I just copied all the files at once. I'll try copying those four files in the order you've listed first and then the rest of the PHTSYS files. That's the only thing I can think of that I did differently (other than having more space in PHTDTA to load all the music) between creating the 10 GB DMS and the 120 GB DMS last night.
-
do a scandisk and see if it finds any bad blocks... if it does, get it replaced... that COULD explain it
-
Okay, running scandisk will be the next step. If that checks out, I'll redo the DMS and try it again.
-
Well, I scanned the disk and no errors were reported so I added the linux, linux.sig, ramdisk, and ramdisk.sig files to the PHTSYS partition. I then copied the rest of the PHTSYS files. I then copied the contents of the PHTDTA partition. After unplugging the phatbox from the car for 10 seconds, I plugged it back in and put the 120 GB DMS cartridge in. I selected CD on the HU and heard "welcome to the phatnoise car audio system". I finally have a working 120 GB DMS!! Now I just have to straighten out some playlist and PMM issues and I'll be all set. Thanks again to everyone who helped.
-
Just out of interest, which linux did you put on the disk. The original or the LBA version?
-
Every file I copied to the new DMS cartridge (both PHTSYS and PHTDTA) came from the original 20 GB DMS that I had been previously using.
-
I'm beginning to think that it might be the 120GB WD drive. I purchased a 120GB 2.5" Scorpio drive from the big blue electronics store (Best***), and had issues when trying to create a new DMS drive with it. During the creation process it would seem to be very jerky during the WMI process (don't remember the exact display but think it was 'Searching for WMI' or something) and would end up creating 2 partitions named PHTDTA. I renamed the 69MB partition to PHTSYS and manually copied the files to it per this posting from VorTechS (http://forum.phathack.com/index.php/topic,1226.msg7865.html#msg7865). I would then try and open the DMS in Media Manager V3.92 and would get 'Delayed Write Errors' in Windows XP.
This happened numerous times and before reading this thread I started thinking it was an issue with the SATA raid on my eVGA motherboard since the SATA drives are listed as USB drives and are hotpluggable on this MB. I took the drive back and replaced it with a 160GB Hitachi and that gave me the same indications and results so I loaded the Phathack tools onto my work laptop and created the new DMS drive on that with no issues. I'm starting to think that I may have been experiencing 2 seperate problems, the first is with the SATA raid and the fact that they are shown as USB drives might have been confusing the PhatHack Tools and the second was just the 120GB WD Scorpio drive. After I replaced the drive I haven't had a single issue with it.
-
It's connected via USB so it is USB as far as you are concerned. If you're getting delayed write failed, it could be a bad cradle, incompatible cradle, or bad drive. I believe that with >127GB drives you need the USB 2.0 cradle. I got all kinds of errors when I tried to use the 1.0 cradle...
-
I have a USB2.0 cradle. When I plugged my cradle into my work laptop (an HP 6910P) it worked beautifully to create a new DMS drive on my 160GB Hitachi (model HTS541616J9AT00 160GB). When reviewing the logs on my PC with the SATA raid I would see:
Starting WMI Cycle [waiting for WMI to mount partitions and assign drive letters]...
Checking mounted drives for disk...
[Cycle 1] Re-checking mounted drives for disk...
....
Re-checking WMI device list....
[Cycle 60] Re-checking mounted drives for disk...
Re-checking WMI device list....
Checking available disk space...
...which is: 159,974,776,320 Bytes.
LBA Check reports: 159 GB
LBA kernel required: True
Preparing format parameters....
PHTSYS Arguments: -n PHTSYS -f 2 -F 32 0
PHTDTA Arguments: -n PHTDTA -f 2 -F 32 F: 312450735
Formatting PHTSYS....
completed: Failed!.
Formatting PHTDTA....
The 60 cycles of rechecking mounted drives for disk tends to tell me that the PhatHack tool is having a tough time determining which drive is the DMS. As soon as I connected the cradle to my HP laptop it only when through 1 cycle and completed the creation of the DMS very quickly.
I don't know if it matters but my MB is an eVGA nForce 650i Ultra with 4 SATA ports that can be configured as RAID 0, 1, 0+1, and 5.
-
One useful thing to do would be:
- Delete startup_sequence.txt from My Documents
- Start the DMS Hack Tools with the 'faulty' drive active in the cradle
- Close the tools
...and then paste the contents of startup_sequence.txt
There might be a clue there as to what's going on, as that is the initial WMI snapshot that occurs to determine the devices to show in the dropdown. Not sure if it's posted in the WMI cycle part of the logs or not. (Don't have anything to hand to check)
IIRC, although I'll need to check it out tomorrow, the DISK ID is stored as per the selection in the dropdown and so any WMI query is performed against that specific disk ID. The WMI cycle is actually checking for the existence of more than 1 partition. I can't remember if it's explicitly 2, or more than two partitions. I have seen instances before the tools were complete of DMS drives ending up with 3 partitions and perhaps I haven't coped with something like this and perhaps your WMI snapshot is reporting 3 partitions for the DMS.
Again, I can't really clarify this until I see the log.
-
VorTechS,
I won't be able to get you the startup_sequence.txt after deleting it for the WD drive since I've already returned it for the Hitachi, if you want I can email you both startup_sequence.txt files, but I was able to copy it from my system from when I tried using the DMS Hack Tools on it so here is the Win32_drive list for the WD 120GB:
Win32_Drive List
----------------
Starting device evaluation:
Determining device signature...
done.
Disk ID: 1
Disk Name: NVIDIA JBOD 74.53G
PnP Device: SCSI\DISK____NVIDIA__JBOD______74.53G\2
Disk Unique ID (not serial!): D7E9D7E9
Partitions List
---------------
No logical disks available for device partitions.
Device evaluation complete.
Next device evaluation:
Determining device signature...
done.
Disk ID: 0
Disk Name: NVIDIA MIRROR 74.53G
PnP Device: SCSI\DISK____NVIDIA__MIRROR____74.53G\1
Disk Unique ID (not serial!): BC97BC97
Partitions List
---------------
Partition: Disk #0, Partition #0
Drive: C:
Serial #: 18AF5A18
Partitions List
---------------
Partition: Disk #0, Partition #1
Drive: D:
Serial #: D457CA19
Device evaluation complete.
Skipping device with no signature.
Skipping device with no signature.
Skipping device with no signature.
Skipping device with no signature.
Next device evaluation:
Determining device signature...
done.
Disk ID: 6
Disk Name: USB-HS WDC WD1200BEVE-0 USB Device
PnP Device: USBSTOR\DISK&VEN_USB-HS&PROD_WDC_WD1200BEVE-0&REV_0.01\6&3A61BD89&0
Disk Unique ID (not serial!): 0
No disk partitions available for device.
Device evaluation complete.
Succeeded....enumerating devices....
Device 1
Checking device name for USB context...
Not a USB labelled device.
Device 2
Checking device name for USB context...
Not a USB labelled device.
Device 3
Checking device name for USB context...
Not a USB labelled device.
Device 4
Checking device name for USB context...
Evaluates to true!
Does not have drive letter!
Device enumeration complete.
Starting Device Listing....
Getting Device Snapshot....
and here is the Win32_drive list for my 160GB Hitachi drive I'm currently using
Win32_Drive List
----------------
Starting device evaluation:
Determining device signature...
done.
Disk ID: 1
Disk Name: NVIDIA JBOD 74.53G
PnP Device: SCSI\DISK____NVIDIA__JBOD______74.53G\2
Disk Unique ID (not serial!): D7E9D7E9
Partitions List
---------------
No logical disks available for device partitions.
Device evaluation complete.
Next device evaluation:
Determining device signature...
done.
Disk ID: 0
Disk Name: NVIDIA MIRROR 74.53G
PnP Device: SCSI\DISK____NVIDIA__MIRROR____74.53G\1
Disk Unique ID (not serial!): BC97BC97
Partitions List
---------------
Partition: Disk #0, Partition #0
Drive: C:
Serial #: 18AF5A18
Partitions List
---------------
Partition: Disk #0, Partition #1
Drive: D:
Serial #: D457CA19
Device evaluation complete.
Skipping device with no signature.
Skipping device with no signature.
Skipping device with no signature.
Skipping device with no signature.
Next device evaluation:
Determining device signature...
done.
Disk ID: 6
Disk Name: USB-HS Hitachi HTS54161 USB Device
PnP Device: USBSTOR\DISK&VEN_USB-HS&PROD_HITACHI_HTS54161&REV_0.01\6&36F40571&0
Disk Unique ID (not serial!): 0
No disk partitions available for device.
Device evaluation complete.
Succeeded....enumerating devices....
Device 1
Checking device name for USB context...
Not a USB labelled device.
Device 2
Checking device name for USB context...
Not a USB labelled device.
Device 3
Checking device name for USB context...
Not a USB labelled device.
Device 4
Checking device name for USB context...
Evaluates to true!
Does not have drive letter!
Device enumeration complete.
Starting Device Listing....
Getting Device Snapshot....
Both of the above Win32_drive lists were on my eVGA motherboard system.
Below is the one from my laptop with the Hitachi drive
Win32_Drive List
----------------
Starting device evaluation:
Determining device signature...
done.
Disk ID: 0
Disk Name: FUJITSU MHY2080BH
PnP Device: IDE\DISKFUJITSU_MHY2080BH_______________________890B____\4&440D8FF&0&0.0.0
Disk Unique ID (not serial!): 8E608E60
Partitions List
---------------
Partition: Disk #0, Partition #0
Drive: C:
Serial #: 2CC0BF8E
Device evaluation complete.
Next device evaluation:
Determining device signature...
done.
Disk ID: 1
Disk Name: USB-HS Hitachi HTS54161 USB Device
PnP Device: USBSTOR\DISK&VEN_USB-HS&PROD_HITACHI_HTS54161&REV_0.01\6&1BC8F8E4&0
Disk Unique ID (not serial!): 1AE63130
Partitions List
---------------
Partition: Disk #1, Partition #0
Drive: F:
Serial #: 478830CA
Partitions List
---------------
Partition: Disk #1, Partition #1
Drive: G:
Serial #: 478830CC
Device evaluation complete.
Succeeded....enumerating devices....
Device 1
Checking device name for USB context...
Not a USB labelled device.
Device 2
Checking device name for USB context...
Evaluates to true!
Also has drive letter!
Device 3
Checking device name for USB context...
Evaluates to true!
Also has drive letter!
Device enumeration complete.
Hope this helps. As I said above, I can email you both of the startup_sequence.txt files and the PhatHack_NewDMS_Log.txt files if that would be helpful.
Greg
-
The New_DMS log might be useful, but as I see it from what you've pasted there are no partitions being reported by WMI, or an error has occured that I'm trapping and assuming it's to do with a non-DMs device.
What O/S are you running on the RAID machine?
-
I'm running WinXP SP2 on both my PC with the SATA Raid and on my HP 6910p laptop.
-
Try accessting the drive (copying to it or something) with all versions of PMM closed. I thought it was fixed but some versions of PMM had issues with 160GB drives. See http://forum.phathack.com/index.php/topic,620.0.html