X32 BSODing on Fujitsu Siemens Laptop

Hi All.

I recently purchased myself a Corsair X32 SSD (PN: CMFSSD-32D1) from Scan Computers in the UK and installed it into my Fujitsu Siemens Amilo M3438G laptop. I cloned my existing XP installation from my old 80GB Samsung HDD (Being sure to resize the partition on the disk first) using ddrescue under Ubuntu 9.04, and then booted my laptop with the SSD. Very happily blown away by the

However.

It would seem there is some kind of incompatibility somewhere along the way, as any kind of extended use (Unfortunately by 'extended' i mean about 15 minutes) results in the machine gradually locking up, eventually resulting in a BSOD, 0x000000F4 (0xF4 - Critical Object Termination). The first parameter indicated that it was a process that terminated, as opposed to a thread, but I dont really think that matters much.

A reboot and the machine appears fine, but another 15 minutes and the problem reoccurs.

Since this started I've been trying everything I can think of to test or debug this issue, so here's what I've tried/tested so far

• The SATA support in my laptop is non-native, provided by a VIA VT6421 RAID controller. I am provided with few configuration options, particularly no option to set to "IDE" or "AHCI", but the controller is *not* configured to provide any level of RAID.
  
• The VIA VT6421 is SATA 150 only. I was aware of this when buying the drive, i still felt it was a worthwhile upgrade, and the FAQ on this forum suggests that the drives are fully backward compatible.
  
• The SSD appears to work fine on more modern machines, though all of my other machines are SATA 300 capable, so i am unsure if that discrepancy is of any significance.
  
• Being that the VT6421 is a non-native controller, I have to integrate a RAID driver into my installation. I've tried several different drivers; The one provided by Fujitsu Siemens as well as a few others found around the web, though as far as i can see the VIA website's recommended package for a 'Latest Driver' provides a file that contains no driver for my hardware.
  
• The installation of XP on my laptop originally was a pretty heavily modified ("nlited") installation, however I've been doing this for a number of years and the modifications were pretty much entirely integrating updates & drivers and making cosmetic changes, and I'd not had any problems with this installation for the month or so I'd been running it up to this point. A 'clean' install of Windows XP Home SP3 (including only the RAID driver, obviously) behaves the same way, however i do get balloon popup messages; "Unknown Hard Error" leading up to the BSOD.
  
• Windows 7 behaves much the same way, though I've not actually successfully gotten this completely installed, I've got the BSOD several times during setup.
  
• Ubuntu 9.04 seems to struggle with the drive at first, but then sets the drive to UDMA33 and seems to continue quite happily. I think this may possibly lead to my 'salvation'. (Also, the original drive clone was done on an SATA 300 machine using Ubuntu 9.04, Though as I say the drive seems to be fine on other machines)
  
• My laptop supports two fixed disks, my original motivation to get an SSD, as I figured I could use the SSD as a boot drive, but keep my personal data on a secondary, larger traditional HDD, and get the best of both worlds. The issues didnt arise until I fitted a second hard disk (rather foolishly, my old 80GB Samsung, formatted and repartitioned), however I have now tried every combination of Drives in Bays and the behaviour is consistent across the board.
  
• Performance tests using HDTach seemed to demonstrate that the controller was limiting the drive to around ~100MB/sec (a surprisingly flat graph, hehe) which while relatively terrible for an SSD, was still awesome fast compared to the old drive, and the main benefit of near-zero access times were absolutely wonderful. Also, i'm basically immune to this pesky SSD slowdown that the TRIM command is supposed to fix.
  
• Just 'to be safe', I've tried reinstalling XP on the original HDD from this laptop (I need something to run it with, anyway) and I have had no issues with it since (two hours and counting). I wanted to rule out the possibility that I had in some way damaged my laptop while fitting the SSD, but it would seem this isn't the case.
  
• 23-09-09, 1400 GMT - Following Davyc's suggestion of creating an aligned partition to install into, the problem still occurs.
  

After all i've tried i'm pretty sure that there is an issue with the VT6421 controller in my laptop. I'm expecting that it was never really designed to be up against devices capable of 200MB/sec, though of course if it followed the SATA spec this shouldnt be an issue.

I'm pretty sure my only remaining option is to try to limit the SSD to UDMA5 / ATA100, which may be a bit of a crime against SSDs everywhere, but as HDTach has shown I wouldnt really lose anything throughput-wise, and I'd get to keep my access times and generally speedier drive, rather than go back to the 30MB/sec of my older drive.

Problem is, I've not yet found a way to limit the SSD in such a way. hdparm within Ubuntu can be used to set an access mode, though that doesnt seem to 'stick' between reboots, as is the case with HDAT2. Windows itself offers a similar option in Device Manager for IDE controllers, but unfortunately the VT6421 installs itself as a SCSI controller, so I dont have this option. I wanted to investigate the possibility of applying a registry tweak somewhere but googling for "XP limit UDMA" or similar just returns hundreds of results with people with drives stuck in PIO mode (I have tackled this problem myself in the past, so I can hardly blame them) so I'm looking for a needle in a haystack. Various drive manufacturers supply tools for changing the UDMA mode of their drives, but obviously these utilities are limited to their own brand of drive, and Corsair dont appear to have a similar utility.

Somehow I dont think it is the case, but could there be an issue with Corsair SSDs and SATA 150 controllers? I understand that it's 'supposed' to work but given the relatively high cost of SSDs and their performance, I cant help but wonder if their use on SATA 150 systems is fairly rare, so any issues like this may have just not come to light yet?

It's looking more and more like i'm going to have to return this drive, as much as i'd really rather not, but before I do, my question is:

Is there any way for me to configure the SSD itself to be 'limited' to UDMA5/ATA100? Could a firmware update fix this?

I'm also widely open to any other suggestions. I really dont want to have to go back to spinning platters.

Thankyou for reading all that.

- D

Did you align the drive first? XP does not automatically align partitions - if you search the forum for DISKPART you will find out how to align your drive for XP.

Also, taking an image from your HDD is not ideal - it's always a pain to fresh install, but it does help to eliminate a lot of problems that can occur either during or later, including BSODs.

Align your drive, take an image once you've got everything the way you want it and you can use that image in the future on your drive.

I notice you tried windows 7 which does align your drive correctly .... it seems most likely to be a driver issue, did you try getting in touch with the m/f of your laptop to ask about the SATA setup and any possible workarounds?

One more thing - just an observation ... I've noticed that most issues regarding problems are related to LapTops with very few for desktops. I doubt very much that the drive is the issue as you have tried it on other machines.

Hi Davyc, thanks for your prompt reply.

I didnt perform any specific alignments, generally speaking this is not something i have had to do in the past when performing operations such as this but as i have said, I'm willing to try anything. I'm using my Windows 7 disk to set up an aligned partition now, and will attempt reinstalling my XP installation onto that partition once it is complete. I'll let you know how that works out.

FujitsuSiemens have been notoriously tight-lipped on the support front, efforts in the past to secure information as simple as if the controller supports 48-bit LBA (drives larger than 137GB) have been met with resignation and half-answers, I'm reluctant to try to get anything from them on this subject simply because past experience suggests i'm going to get nothing but an inflated phone bill.

I must agree that I think the drive itself is fine, It performs wonderfully in my desktop, but as i cannot rule out the possibility of an issue with the SSD and SATA150 controllers i felt i should mention that.

Ultimately I believe the problem is with my controller, and that unless I can convince the SSD to run permanently at ATA100/UDMA5, I'm going to have to return it.

I just want to exhaust all other possibilities. This SSD is too nice. I dont want to go back, heh.

Cheers

- D

Yeah it would be a shame to send the drive back because of a controller issue with your LapTop ..... seems like the Far East Troop are not gee'd up on giving good customer service; they're happy enough when we're buying their gear but after that you're left adrift.

Alignment is very important especially where XP is concerned as a misaligned drive performs poorly and can cause numerous problems. Hope everything works out for you and you can get the drive to function as you want it in your LapTop.

Okay, I've just got the same error during Windows XP Setup using an aligned partition as described in this post, using the CLEAN ALL command as at this point this SSD has seen a fair bit of action.

It would seem that this particular case has no alignment issues.

Any other suggestions?

OK I've been doing a bit of digging on the Via forums and it seems to be a recurring problem for a lot of people (not just with SSDs) and the consensus of opinions appear to be that this particular Via controller is not compatible with Sata II. It's a shame really because you're limited as to what you can use with your computer.

Have a dig into the forums and see if you can find anything helpful here at the Via Forums

Cheers Davyc

I had come across a few opinions along the lines of "This controller doesnt support SATAII, SATAII devices will not work", but in my experience this was only initially a problem when drives first came out, then manufacturers added jumpers to drives to limit them to SATAI, which relieved the problem.

I'm not seeing these jumpers so often nowadays, after reading the FAQ on this forum i assumed that newer drives had some kind of auto-detect mechanism installed; Saying the drive is backward compatible with SATAI seems to suggest the drive will play nicely with an SATAI controller.

Running with the assumption that it is the existence of SATAII capabilities in the SSD tripping me up, is there anything we can do about that? I seem to remember the jumper on the X32 is there only to enable firmware updates, is there any way we can lock it to SATAI?

This seems to add some credit to my original idea of limiting the drive to UDMA5/ATA100, though...

Thanks again

- D

Update: It seems the VIA VT6421 lacks the SATA AutoNegotiate feature meaning, presumably, that the SSD is trying to operate at SATAII speeds, or something similar, so it sounds like 'locking' the drive to SATAI is what's needed.

After further research, Samsung, Hitachi et al. supply utilities to do this to their own disks since they stopped including jumpers to limit the performance, is there a generic or Corsair-specific utility for this?

I think this is a question best answered by Ram Guy ... because of the time zone differential it will probably be around 6:00pm or so GMT before he will be here.

This appears to be a problem that is cropping up more and more as new hardware supercedes old hardware and never the twain shall meet; it's hard lines for those who have older hardware that functions perfectly well and suits their needs only to find that the new generation of gear doesn't want to play.

Indeed, honestly i wasnt expecting any replies until long into the evening (GMT)... I'm glad to have ruled out some possibilities and get a second opinion on some stuff in the meantime, if not a solution.

I have to admit i'm feeling a little shortchanged here, but unfortunately it's difficult to lay the blame with anyone; I suppose technically it's VIA's fault, but Corsair do advertise their SSDs as SATAI compatible...

It is somewhat promising though that it would seem a limiting utility is both theoretically possible and likely to solve the problem.

Things are certainly looking less bleak than they did this morning.

Thanks Again

- D

Hi RAM GUY

Just to be clear, I'm not looking to modify the SSD, not in any permanent fashion. Much as older drives used to have jumpers on the back of the drive to limit their speed to SATA I, newer drives from samsung, hitachi, western digital etc. can be limited by use of manufacturer-specific utilities (Hitachi's, Samsung's, others), presumably to save the cost of those terribly expensive jumper pins, heh.

My understanding of it is that this is a fairly standard feature of the ATA spec, just that nobody has written a generic tool, presumably because manufacturer tools exist for most drives.

Is there no such tool in existence / planned for Corsair drives? If not, might I suggest updating the product information page to stop people walking into the same trap I did?

I understand I am an edge case, I am not holding Corsair responsible for my controller's shortcomings, but it might be helpful to let other people know this is a possibility if there is no intention to implement a workaround.

Thanks

- D

Thanks for the prompt reply RAM GUY.

What I was looking for was a utility, possibly windows-based or possibly bootable, to limit the drive itself, in hardware, to a lower speed. As I have said these are common amongst traditional hard disks.

If no such tool is available or expected then fair enough, that's all I wanted to check really, it appeared it was my one hope for solving this problem.

Sorry for my slightly unusual questions, and thankyou for all the prompt responses, both RAM GUY and Davyc.

Cheers

- D