SEO - Search Engine Optimization - Search Engine Marketing - SEM
iTunes Beatles Billboards
Intellectual Predator Email this Page
Data Loss on QUANTUM FIREBALL TM Series EIDE Harddrives: Research History and Tests Conducted
Return to Quantum Data Loss page, my Harddrive Terms&Tricks page or to the COMPUTERCRAFT main menu
Copyright (C) 1997 by Erik van Straten. All (registered) trademarks are recognized.
Last major change: 02/13/1997 by EvS. Last file modification:
RESEARCH HISTORY AS OF FEBRUARY 13, 1997
- On October 1, 1996, I received most of the ordered components for assembling 4 PC's, 3 for users at work, and 1 to be used by (and payed by) a private user. This included 4 Quantum Fireball TM2100A EIDE drives, all had Firmware Rev. A6B.1F00. In the days that followed I received the missing components and started assembling 3 PC's, the components for the fourth PC were taken home by the private user. I took the 3 drives home for testing and software installation on friday, October 4 (yeah, I know, I'm a workaholic, but I don't get disturbed at home that much, and testing/software installation take place on my PC while I pay attention to my family again).
- On October 6, I suddenly found that on the drive I was working on, most of the software I just installed had disappeared! It took me a lot of time to find out what went wrong, and how to reproduce it.
- I did a lot of testing the week that followed, on a number of different PC's. All PC's were tested with and without additional drives (including ATAPI CDROM drives) connected. The Asus T2P4 motherboard based PC all have SC200 SCSI controllers installed, used for the CDROM and possibly future ZIP drives. The Plato motherboard based PC has a Mitsumi FX400 CDROM player connected to the secondary IDE controller, tested it both with and without. My PC at home has an old Mitsumi FX001D drive with proprietary ISA controller installed. Similarities between the PC's tested are that all have 32MB RAM and Diamond Stealth 64 VRAM based graphics controllers (S3-964 in the Plato; S3-968, "Video", in the others). Note that the bugs showed with either standard VGA drivers (in the "generic" test-setup) or S3 drivers installed. Since 32BDA is required in order to get the problem, I also connected a WD harddisk as a slave drive and tested the setup with WDCDRV.386, Western Digital's 32BDA driver (it won't run if you don't have a WD drive connected) and was still able to reproduce the problem. It showed up on all following PC's, thus eliminating the motherboard/BIOS combination to be the cause of the problem:
- My private PC at home: Biostar MB-8433UUD motherboard, Award BIOS, AMD5x86 133MHz (486 clone)
- My PC at work: Intel Plato motherboard, AMI BIOS, Intel Pentium 90MHz
- The 3 PC's at work the drives were intended for: Asus T2P4 Rev 2.3 motherboard, Award BIOS, Intel Pentium 166MHz.
- I installed the same software configuration on a Western Digital 1.6GB drive (WDAC31600) I had laying around for another PC. Whatever I did, under similar conditions as on the Quantum drives, I was not able to reproduce the problem on the WD drive.
- On friday October 11, I finished a report about the problems and submitted it to Quantum tech. support UK by fax, and to Ontrack tech. support USA by email. Right after that, I returned the 3 drives to my local supplier and exchanged them for 3 Western Digital 2.1GB (WDAC22100) drives that happened to be on stock. The private user's drive was replaced on monday, October 14. By the way, I had all returned drives configured with a "generic" test-setup consisting of only DOS, WfW and ONTRACKW.386 V1.06 (the 32BDA driver). I was able to reproduce the problems with that configuration in the new Asus T2P4-based PC's I was building. However, I made a mistake by not testing that "generic" configuration in the other previously tested PC's as you''ll see later. I shipped the drives with the buggy configuration installed and added my report on file, and as a paper copy as well.
- The WDAC22100 drives even have the same BIOS setup parameters as the Quantums did: 4092 cylinders, 16 heads and 63 sectors/track. Of course I tried to reproduce the problem on them, just as I did on the 1.6GB drive, without "success". In fact, I tested a number of other PC's in the group where I work, and on none of them I was able to reproduce the problem.
- It took until October 17 before Quantum UK replied.They offered to send me a new firmware release to update my drives. I replied to them that I no longer had the drives, and that my local supplier had returned them to the Dutch distributor. I provided Quantum with the address of the Dutch distributor and informed them of the serial numbers of all 4 drives returned (my report mentioned only three drives because I did not have the drive of the private user while writing the report).
- After October 17, some kind of radio-silence started. My local supplier had more drives on stock and did not want to sell them before he knew more. And the Dutch distributor would not take them back because Quantum would not confirm any problems. Althoug all of this actually could be considered none of my business since I didn't have Quantum drives anymore, I still felt responsible somehow. I started reading Usenet news, mainly comp.sys.ibm.pc.hardware.storage, hoping to find someone reporting similar problems. Note that I promised Quantum that I would not publish about the problem for 2 weeks after I submitted my report, giving them a fair chance to fix the problems and issue a warning themselves, if possible, on their website.
- After October 28, Chris Unsicker posted an article titled "Quantum Drive Trashed by Windows Restart" in newsgroups comp.sys.ibm.pc.hardware.storage and alt.sys.pc-clone.gateway2000. He experienced the same problems as I did with a dozen new Gateway2000 Pentium based PC's. After he made some changes in the Windows network setup, the PC would reboot as usual. However, the reboot would fail with an error message "Non System Disk" while the rest of the drive-contents became a mess. This eliminated one common factor possibly causing the problem: me.
- On October 29, I asked Quantum about the status of the problem. They replied the next day and wrote me that not much progress had been made on the issue, and offered to loan me a drive so I could test the new firmware. As it seems to me, they simply didn't believe me, which is not really amazing since they probably did not receive any other similar reports. Typically users will blame their harddisk when they get messages like "Sector not found reading drive X" or alike. But when suddenly subdirctories have disappeared they will probably blame the operating system, the application used or themselves and not the drive; this really is not a common error. And further, most users switch off their PC's right after quiting Windows (some do before, which can trash any drive).
- On October 30, I posted an article titled "Dataloss on recent Quantum Fireball TM series EIDE harddisks" to a number of usenet news groups (alt.comp.periphs.mainboard.asus, comp.sys.ibm.pc.hardware.storage, comp.os.ms-windows.misc, comp.sys.ibm.pc.hardware.misc, comp.os.ms-windows.nt.misc and alt.sys.pc-clone.gateway2000). In that article I asked anyone with similar experiences as I had to report this to me. Although I received a lot of emails, unfortunately none of them described similar data loss as Chris and I experienced. But then, my post was actually too long, and not too many people read news (there are al lot more people posting than reading news it seems, and a lot of posting people ask for a reply by email). Anyway, Anthony Olszewski read my post and asked me if I allowed him to publish it on his webserver, www.computercraft.com. I agreed, and the text you're reading now is more or less based on that usenet post.
- I replied to Quantum that I was prepared to test a drive, provided that I would be allowed to publish about it, either in computer magazines or on the Internet. Another condition was that I (or my boss) would not have to pay for shipping the drive back. I was prepared to invest my own time in it without charge, however. Quantum agreed on my conditions and shipped me a Fireball TM2110A on friday, November 1 (note: TM2110, I had TM2100's before). The new Fireball TM2110A drive they sent me has Firmware Rev. A6B.2400.
- I received it on monday afternoon, November 4, and mounted it in my own PC at work (the Plato-based PC). I copied my backup of the "generic" test-setup to the drive and started testing. I was not able to reproduce the bugs anymore, so I figured Quantum had fixed them with the new firmware. To make sure, I asked one of the users of the new PC's to go home early, and connected the new drive to that Asus T2P4 based PC and started testing, and found:
===> the problem showed up again! <===
After a lot of testing until late that night I found that I had missed some relevant parameters in my "generic" test-setup. In that setup, which I created before writing my first report, I had let windows decide about the size of the permanent swapfile. It suggested 125MB and I simpy agreed. I was able to get errors with that configuration on the Asus T2P4-based PC's, but not as often as with my normal pre-installed sofware setup (Windows + drivers +applications etc.). In the latter I ususally set the permanent swapfile size to 32MB or 48MB, depending on how much RAM is installed and what type of programs the user wil be using. Generally, in AUTOEXEC.BAT, I set up Smartdrive as: C:\DOS\SMARTDRV.EXE /X 2048 128 which returns most RAM to Windows. With that 125MB swapfile configuration, I did not return to the other PC's to verify that the problem would still exist on them as well. I assumed that the errors would reproduce, and blamed the fact that the errors did not show up as often (with this "generic" test-setup on the Asus T2P4-based system) to the fact that much less files were on the drive. Again, that assumption by me was wrong! Sorry about that. However, by October 11 the delivery of the PC's had already been delayed by more than a week. I just wanted to have the drives replaced as soon as possible after having proved that the they were to blame and describing that in my report.
- On monday night, November 4, I found that the size of the swapfile really mattered, especially if it was smaller than the cache size specified for smartdrv. I conducted a large number of other tests. Cycles refers to the number of REPEAT/UNTIL loops I tested to see the problem. In short, these were the tests conducted:
- Similar hardware between test PC's is not the cause. I replaced my PCI Diamond Stealth 64 Video VRAM with a good-old ISA ET4000, because I realized that all PC's I had tested had an S3 based Video controller. With the ET4000 I had the same error-rate however, about 8 out of 10 cycles were bad. I also tested with only 16MB DRAM installed, since all PC's I used for testing had 32MB. Did not make a difference. All other hardware varies a lot.
- HDD Blockmode/Multiple Sector Transfers/Interrupt is a factor. I disabled "HDD BlockMode" (at home, Award BIOS in Biostar MB) and Harddisk "Multiple Sector Setting" (at work, AMI BIOS in Intel Plato). With that multi-block transfer disabled, I was NOT able to reproduce any errors. It is clear that this setting is of influence.
- Different PIO modes have a small influence. I experimented with various PIO modes. My Award BIOS at home allows modes 0, 1, 2, 3, 4 and AUTO (which turns into 4 for these drives). All modes showed errors (if the other conditions were met). However, a lower PIO mode seems to yield a lower error-rate. At work in my Plato/AMI I could only "Disable" or have "Fast PIO MOdes" "Auto Detected": both modes showed errors. No real difference in error-rate found there.
- ONTRACKW.386 32BDA driver is NOT the cause! I wanted to know whether ONTRACKW.386 is involved. Someone suggested to use only the first 504MB of the drive, in order to be able to test the WfW built-in 32BDA driver *WDCTRL. So, in my BIOS I had the 2.1GB Quantum configured manually as follows as a WD1003 compatible drive without translation:
|TYPE ||SIZE ||CYLS ||HEADS ||PRECOMP ||LANDZONE ||SECTORS ||MODE |
|USER ||528 ||1024 ||16 ||65536 ||4092 ||63 ||NORMAL |
After clearing the last 2 bytes (55 AA) of the MBR (using Norton Diskedit) I rebooted the PC, ran FDISK and made 1 full-size primary partition (528MB where M=1E6, this equals 504MB where M=1024x1024). Then I formatted it using DOS format /s. I copied DOS and reinstalled WfW311 (NOTE: reinstalled, not copied it). I switched off "Save Settings On Exit" in Program Manager, enabled 32BFA and 32BDA (the entry was NOT grayed, so *WDCTRL can be used), and set the swapfile size to 2MB. Did not change the min. VCache size which was set to 4,096KB by default (in my 32MB DRAM PC).
With that setup, the errors ALSO SHOWED! In fact, I saw the error 8 times in 10 cycles.
This means that ONTRACKW.386 is NOT causing the problem, but 32BDA in general is involved, and using Microsoft's internal driver *WDCTRL has the same effects as ONTRACKW.386 (and WDCDRV.386 which can only be used when a WD drive is connected as well). I was pretty sure about this already since the same config with ONTRACKW.386 workes fine with my Western Digital WDAC31600 and WDAC21200 drives (among others). BTW, the WDAC21200 has the same LBA BIOS params (4092 cylinders) as the Quantum TM2100A and TM2110A drives.
- Error parameters on a 504MB partitioned drive. With WfW311 using *WDCTRL as 32BDA driver I did some more tests.
- Disabled 32BDA and 32BFA, TEMPORARY swapfile size 20480M: no errors.
- Enabled 32BFA only: no errors.
- Enabled 32BDA and set swapfile to permanent: errors came back, about 6 out of 10 cycles were bad.
- Increased Min. VCache Size from 4096K to 8192K: 8/10 cycles bad.
- Decreased Min. VCache Size from 8192K to 521K: 9/10 cycles bad. Guess that's just statistical noise.
- Switched on "Save Settings On Exit": 0/10 errors! However, on a full software installation I have also found errors when this was enabled, so it's NOT a cure for the bug! Aparently writing to the disk (apart from updating the date/time of C:\386SPART.PAR) during the windows-session seems to decrease the error-rate.
- Ontrack Diskmanager's DDO prevents errors?! I cleared the MBR with Norton Diskedit. Used "Autodetect harddisk" in my BIOS but chose "NORMAL" translation instead of LBA. Ran Ontrack Diskmanager V7.12 (from www.quantum.com) and it installed the DDO (Dynamic Drive Overlay) as I expected. Partitioned as follows: C: 1072MB, D: 536MB and E: rest (500MB). I generally choose such partitionsizes because they will allow the max. number of smallest possible clusters in them (note that M=1,000,000 for Ontrack). Then I copied my "generic" test setup to C: and used the following settings:
- SMARTDRV /X 8192 8192
- ONTRACKW.386 loaded, 32BDA and 32BFA enabled
- Min. VCache Size 512K
With this setup, I was NOT, repeat NOT able to get errors! This config shows errors in all other situations when DDO is NOT loaded.
- Yet Another Verification Of The Problem. I reset the drive to LBA-mode in my BIOS and booted from floppy (otherwise DDO cloaks the "real" MBR), and ran WD_CLEAR to clear all sectors on the drive (fill them all with 0-bytes). Took approx 15 minutes BTW. Used DM again to partition/format the drive fast (not installing the DDO now) into C: 1072MB, D:536MB and E: rest (500MB), so the same as before, but now, without DDO. I copied my "generic" test setup and re-tested things, again with the basic settings listed above. This gave me 7/10 errors. This indicates that the DDO loaded prevents the errors in an otherwise similar configuration.
- Some additional tests on my Intel Plato/P90 on 961105, in chronological order:
- My "gereric" testsetup described under 8 (unchanged): 9/10 errors.
- With the AMI-BIOS "Multiple Sector Setting" set to "Disabled" I had zero errors (0/10).
- With the AMI-BIOS "Multiple Sector Setting" reset to "Auto Detected" and "Fast PIO Modes: Disabled" I even saw 10/10 errors!
- With both "Multiple Sector Setting" and "Fast PIO Modes" reset to "Auto Detected" I saw 8/10 errors.
- With the AMI-BIOS "Boot Options | System Cache: Disabled" my system was -VERY- slow. I guess this disables both internal and external CPU cache. Remarkable: zero errors! (0/10).
- Re-enabled System Cache: 10/10 errors...
- In the AMI-BIOS set "Advanced | Avanced Chipset Configuration | PCI Prefetch Buffers: Disabled": 10/10 errors
- Re-enabled "Prefetch Buffers": 9/10 errors
- Switched off "turbo" mode (don't know exactly what it does, if anything at all): 9/10 errors.
- On November 6, 1996, I submitted my second report to Quantum, roughly containing the information above.
- On November 14, 1996, I was informed by Quantum that they have a new firmware revision under test. They will send it to me as soon as it is released.
- That same day, Nov. 14, I decided to do some more tests. I repeated some of the tests above in my pc at home, and all had the same effect. These tests included different partitioning schemes to make sure that they do not influence the problem, and indeed I found that they do not. I repeated the test with Ontrack Diskamager installed, and again was not able to get any errors with DDO running. I also set it up again as a WD1003 compatible drive and installed *wdctrl and was able to reproduce the problem with that, as before. I also increased the number of rootdirectory sectors manually (using Norton's DiskEdit this can be done, although not easy). I did this because I wanted to know what would happen if I have more than 512 rootdirectory entries. Will I be seing entries out of the first and the sixteenh sector? No. I created more than 600 subdirectories, and still kept seeing only entries out of the first rootdirectory sector. It still makes me wonder why I get "empty" sectors. Where are those zero-bytes coming from? With a problem like this I'd rather expect to see contents of other sectors (like FAT contents).
- On November 21, 1996, I submitted the first version of the page(s) you are reading now to www.computercraft.com. They were brought online on November 24, 1996 if I'm correct.
- On November 22, 1996, Quantum sent me a firmware patch program. They told me that the new firmware had undergone extensive testing and worked fine. I had some problems getting the patch-program to run, but finally I managed to upgrade the drive's firmware to Rev. A6B.2ANO. Unfortunately, the first test I conducted already showed that this patch did NOT fix "my" problem! I was very unhappy about this. Apart from just a few others, I seem to be the only person who has this problem. I nearly surrendered to the idea that I must be doing something wrong. But then, I did so many tests, and results are so extremely reproducable.
- On November 24, 1996, I wrote a program that hooks INT13 (boy do I hate Intel assembler, why didn't IBM pick Motorola for a CPU?!?) and logs some of it's actions. INT13 (also called biosdisk(...) by some C-compilers) is the low-level routine that DOS/BIOS uses to access drives. You pass parameters like the "command" (i.e. read or write), the drive number, and Cylinder, Head, Sector, #Sectors values as well as an address in memory where to put (or get) the data read from (or written to) the drive. A hook is a subroutine that gets activated instead of an original operating system routine, then calls the actual OS routine, regains control and finally returns to the caller. Note that I will NOT give away the mentioned "program", since it consists of no more than a number of hardly documented sources which I recompile for each test I want to do. Don't waste your and my time asking me to send "it" to you.
Since my routine hooks INT13, it can record the passed parameters and buffer (main-memory) contents before and after each request. When 32BDA gets actived, the DOS/BIOS INT13 routine is no longer used; instead the 32BDA driver takes over. Therefore my hook does nothing when 32BDA is active. When Windows and 32BDA are terminated, at some stage control is transferred back to the DOS/BIOS INT13 routine. My program and hook will record the initialization stage of the 32BDA driver and the first INT13 calls after quitting Windows. Some of my findings:
- DOS typically calls INT13 with a sectorcount of 16, i.e. asks the BIOS to read 16 sectors at a time. It also does this for FAT sectors (which are not stored in clusters). This is an optimal situation because modern drives will transfer 16 sectors per interrupt when HDD-BlockMode is enabled. Note that DOS doesn't know if blockmode is enabled or not. The BIOS will decide whether to transfer 16 sectors as one block or read 16 single sectors (or even transfer 4 x 4, 8 x 2 or 2 x 8 sectors).
- During Windows initialization stage, all accesses to the rootdirectory and FAT's happen with a sectorcount set to 1. I am not sure if these calls originate from generic Windows code or from the initializing 32BDA driver. I see accesses to bootsectors of all partitions on all drives, rootdirectories and FAT's. Also I see that some of the *.386 files in the SYSTEM directory are loaded.
- When the 32BDA driver is active, nothing is recorded by my program anymore because it consists of 16-bits code, and the actual INT13 routine is "virtualized" by Windows.
- When I quit Windows, the first thing that happens is that DOS reads the rootdirectory of drive C:, presumably to find where COMMAND.COM is located. And this is where sometimes things go wrong! With my program I was able to see the RAM contents BEFORE this request and AFTER it. To read the rootdirectory, DOS calls INT13 specifying a sectorcount of 16. The memory-address parameter points to a RAM-buffer that (at that moment) still contains left-overs of the C:\DOS directory contents; these were written there just before windows started and have not been overwritten by windows code. So this buffer (16 x 512 bytes in size) contains absolutely non-zero data. After the real INT13 has actually run, that buffer should contain the contents of the rootdirectory (16 sectors). However, this RAM buffer contains ONLY valid entries data from the first rootdirectory sector from the drive, all other "sectors" have been overwritten with zero bytes!
- After having read the rootdirectory using one single INT13 call (and getting erroneous results sometimes) DOS starts reading FAT sectors (also with a sectorcount of 16). I have never seen this fail.
Again, getting erroneous rootdir contents does NOT always happen; sometimes the drive returns all 16 sectors as it should. My findings mean that there REALLY is a problem with these drives, not caused by DOS or Windows or 32BDA. However, it may still be caused by the BIOS or low-level parts of SMARTDRV, which is where INT13 calls go when Windows is not running. Nevertheless, I cannot reproduce this on ANY other harddrive I've tested. I tried to debug into the actual INT13 call but failed. I planned to conduct more tests but these experiments simply use extreme amounts of time (cannot remember having rebooted my PC that often!). My conclusion is that the drive often returns incorrect results, but only during the first BIOS-INT13 call right after 32BDA has terminated. This only happens when the BIOS uses PIO blockmode to access the disk; possibly 32BDA uses some PCI-DMA mode, and apparently the error occurs during the switch-back to PIO blockmode.
Switching blockmodes is apparently known to be dangerous. The following is an excerpt from the file WDCDRV26.DOC (June 1, 1995) which comes with Western Digitals WDCDRV.386 (V2.6) 32BDA driver, under the section Operational Notes:
- "When Windows is configured for a temporary swap file it performs accesses to that swap file through the PC BIOS. A potential conflicts between one blocking factor being used for swap file accesses by the BIOS and another blocking factor being used by all other Windows disk accesses the driver requires special processing by the driver. Thus the driver will not allow the blocking factor to be changed from that selected by the BIOS when a temporary swap file is in use by Windows. Any attempt to change the blocking factor in the SYSTEM.INI file will be ignored. The driver will continue to use block mode transfers using the blocking factor selected by the system BIOS at power-on."
Note that the mentioned WDCDRV.386 driver may not switch blockmodes during a windows session, but at some point it will have to terminate, and then a blockmode switch will occur. Therefore it doesn't surprise me that this driver causes the same error as the ONTRACKW.386 driver does (note that the WD driver will only work when you have at least 1 WD drive in your PC).
- On November 26, 1996, I submitted my third report (which included most of the above information) to Quantum, informing them that firmware Rev. A6B.2ANO does not fix the bug. I asked Quantum to keep investigating the problem.
- On Januari 23, 1997, Quantum informed me that they had finally been able to actually reproduce the problem, and started working on a fix.
- On Januari 28, 1997, I received the patch-program. That same night I tested it thoroughly, and it works! Phew...
To make sure that it really works, I did the following things:
- Before I applied the patch, I first made sure that the bug still showed up (it did).
- Then I applied the patch , which successfully updated the firmware rev. to (A6B.2DNR). Then I did a lot of Windows starts/quits and never saw any rootdir entries disappear.
- Just to eliminate coincidence, I re-applied the OLD patch Quantum had sent me in Nov. last year (which is Rev. A6B.2ANO), and after the first start/quit of Windows, the problem showed up again.
- Finally I applied the new patch (A6B.2DNR) for the second time and was NOT able to reproduce any disappearing rootdir entries afterwards. This proves that the new patch fixes the problem!
I also ran a harddrive benchmark program called checkhd twice before and twice after I applied the patch. There were only slight differences in performance. In the "buffer to host throughput" the numbers would change remain the same, or change by +0.1 or -0.1. However, overall there seems to be a slight performance degradation in that "buffer to host throughput" section, but this could be due to the resolution of the timer used by the program. Fortunately, the speed benchmarks under the section "physical information" were all identical! Also, the buffer size was not changed by the patch (it remains 153 sectors, or 76.5KB).
- On Januari 31, 1997 and the week that followed, I did a number of WfW311 and Windows95 OSR2 installs. This included the installation of one single FAT32 partition on the 2GB drive I have here. There were no signs of problems with the patched drive.
Copyright (C) 1997 by Erik van Straten. I grant Computercraft the non-exclusive right to publish this page. All (registered) trademarks are recognized.
Return to Quantum Data Loss page, my Harddrive Terms&Tricks page
Bruce Springsteen's Jersey Shore Rock Haven!
Great Domain Names For Sale!|
Very brandable Domains for Sale --
The GET NJ family of Sites, managed by Anthony Olszewski, features tens of thousands of Pages Online at dozens of active domains, many with a New Jersey focus. Other advertising opportunities – including enterprise and exclusive placements – exist at a wide range of Web Sites. Your ad can appear at one Page or at many, many thousands of Pages simultaneously!
A large slice of the domains have been Online for more than five years, some for over ten!
In addition to advertising, many great Domains are available for purchase or license
Text Link Advertising Program
Business name, Web Site Link and a brief description or motto runs for one month in the Page (or Pages) of your choice.
Hudson County Politics
From Frank Hague to Robert Janiszewski, in this New Jersey county, political corruption is a tradition. Former NJ Governor Brendan Byrne wants to be buried here so he can stay active in Democratic politics! You'll find lots about Senator Robert Menendez, too.
GRAVE ROBBER Jersey City Computer Repair
297 Griffith Street, Jersey City, NJ - 201-798-2292 - In the Heights just off of Kennedy Blvd. - Very close to Journal Square and Union City, just five minutes away from Hoboken, Downtown Jersey City, Newport, the Waterfront, Secaucus, North Bergen and Weehawken - Tech support for The Jersey City Mayor's Office during the administration of Bret Schundler - PC repair - Tivos, too!, upgrade, hardware install, software install, data recovery, spyware removal, virus removal, replace hard drive, replace motherboard, data recovered from notebook computers, recover lost XP passwords, password recovery
The Statue of Liberty, Ellis Island, and The Central Railroad Terminal
Visit Liberty State Park!