dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
2
share rss forum feed


Dream Killer
Graveyard Shift
Premium
join:2002-08-09
Forest Hills, NY
kudos:1
reply to disconnected

Re: Corrupted SSD S/N After BIOS Update

If the drive works fine, I wouldn't touch it - If it ain't broke, don't fix it.



disconnected

@snet.net

That's been my thought, but when stuff like this happens, sometimes there's a subtle problem that may not be immediately apparent, but may cause other problems that become apparent when doing something more involved than just booting to the desktop. I'm not going to reformat it and go through another week of installing apps, if I can avoid it.



disconnected

@snet.net

Looks like I've got no audio. The C-Media device is gone from the list. I guess there was damage to the drive's content after all. The OS has some corruption--no audio drivers.



koitsu
Premium,MVM
join:2002-07-16
Mountain View, CA
kudos:23
reply to disconnected

said by disconnected :

That's been my thought, but when stuff like this happens, sometimes there's a subtle problem that may not be immediately apparent, but may cause other problems that become apparent when doing something more involved than just booting to the desktop. I'm not going to reformat it and go through another week of installing apps, if I can avoid it.

There is absolutely no harm whatsoever in what you're seeing in that screenshot WRT the S/N. I can explain what's going on there if you want to know, but it's technical; the bottom line is your speculation on this matter is incorrect -- while I understand exactly what you're saying and I agree with the sentiment/thought process, it does not apply to this specific scenario.

You do not need to reformat or do *anything* with your system. What you're seeing is cosmetic. I'm ~99% certain on this. I can speak at further length about the remaining 1% if need be, but it doesn't apply (in that scenario you wouldn't be able to boot your system at all and the drive capacity would show up as 0MBytes).

Your C-Media audio problem is almost certainly something separate/unrelated. There could be an issue with the SSD or the underlying filesystem itself, but that is separate from the "S/N issue".
--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.


disconnected

@snet.net

Thank you for confirming that the problem isn't detrimental. If it's not too much trouble, I would appreciate reading the technical explanation, since I have been unable to find anything useful in a Google search. I'm reading about how SSDs write and read data and about 'write amplification' so I am trying to educate myself on this new technology as best I can.

The sound card problem must have been board flexing from putting pressure on the opposite corner, to insert the RAM modules. I had done an update from 4GB Muskin memory I had since 2008, to 8GB of G-Skill memory. After 24 hours, the G-Skill memory degraded, to the point where it would produce errors at a wide range of addresses in Memtest86+, where a day ago, it passed with zero errors. In putting back the old memory, that board flexing much have slightly dislodged the sound card. I removed and reinserted it and it's back.

However, I have a new problem: SoundForge no longer can select the C-Media device. It now sees only generic Windows sound mapper and direct sound mapper and something else like a legacy Windows mapper. Prior to the fiasco with losing the sound card and reinstalling drivers, I was able to see two hardware devices, plus the Windows sound mapper and directsound mapper. The devices were High Definition audio device (Azalia CODEC motherboard audio) and C-Media device (Turtle Beach Montego DDL. I can no longer select these as the device SoundForge will use. Removed and reinstalled driver several times, but have not gotten that back. I have a lot of programs that play but produce no audio now, and I'm finding that they are defaulted to "Microsoft Sound Mapper", so I try to set them back to C-Media device but cannot find it anymore. Frustrated.



koitsu
Premium,MVM
join:2002-07-16
Mountain View, CA
kudos:23

said by disconnected :

Thank you for confirming that the problem isn't detrimental. If it's not too much trouble, I would appreciate reading the technical explanation, since I have been unable to find anything useful in a Google search. I'm reading about how SSDs write and read data and about 'write amplification' so I am trying to educate myself on this new technology as best I can.

To clarify: write amplification, wear levelling, the FTL (flash transition layer), and all the other "stuff" that makes up an SSD and how it behaves/operates have nothing to do with what was shown in the screenshot. The issue shown in the screenshot is also not SSD-specific in any way; the same problem could happen with an MHDD or a CD/DVD drive or anything else that lives on the ATA (or even SCSI) bus.

I'll expand on the the drive ID/serial number "ordeal" in a later post, when I feel like explaining it / have the desire.

One of the key things I want to make clear here is that you admitted to overclocking the system in some manner (though not now, it was in the past); the effects of this can vary massively, and the damage is often permanent. VRM (voltage regulator modules) acting wonky, and RAM errors are the two the most common things I hear of. The damage is often permanent depending on what all was done -- be aware that I tend to cease providing assistance with PC issues when a user admits to having overclocked their system. I'm very strongly opinionated on the matter, and its based on personal experience dating back to the days of late 90s/early 2000s (think Abit BP6 and later boards).

PCB flexing can sometimes cause problems (especially that several layers are used on present-day motherboards), but I would be surprised to hear that caused a problem -- excessive flexing results in trace(s) being broken or degraded to the point where they can't provide proper voltage/signal any longer. Depending on what the trace(s) are used for, the behaviour varies. Problems of this nature are usually permanent (i.e. "de-flexing" the board will not repair th damage), so the fact you resolved the issue of your sound card disappearing makes me inclined to believe this is not what happened.

"Shifting" the board when inserting DIMMs, thus causing a card to slightly loosen from its PCI/PCIe slot, is very probable. I've done that myself a few times with PCIe x1 cards. Those little buggers' slots aren't long enough to get a good amount of tension/grip in the slot a lot of the time, and backplane screws often cause the cards to pull up out of the slot slightly. I really prefer PCIe x4 (or larger) cards since they have more grip.

My recommendation to you at this point would be to RMA your motherboard. There are multiple "bizarre" things going on which have happened to you that could stem from a board going bad on its own -- the biggest and most prominent is "the board randomly deciding to roll back to an older BIOS (i.e. fail over to the backup BIOS)". This is not supposed to happen and implies something bad going on with the board itself, thus my recommendation to RMA it.

I can't help you with your SoundForge issue. I would recommend starting a new thread in the Microsoft forum asking for help on this (because your issue is certainly driver and/or registry-related), and you can mention this thread's URL as a reference.
--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.


koitsu
Premium,MVM
join:2002-07-16
Mountain View, CA
kudos:23

1 edit

2 recommendations

Click for full size
Section 7.16.7
Click for full size
Section 7.16.2
said by koitsu:

I'll expand on the the drive ID/serial number "ordeal" in a later post, when I feel like explaining it / have the desire.

The serial number of the Intel SSD in the screenshot is displayed as follows:

KI245500UD240DGND

There are a total of 20 bytes (characters) shown here -- the first 16 are the serial number, and there are four (4) trailing "garbage characters". To get them to display here in the forum I used Unicode, but on PCs -- particularly at that point in the boot phase -- you're limited to the character set defined per code page 437 (what most of us older folks call "ANSI" or "PC ANSI" (stemming from BBS days), also referred to as "IBM PC font", "the Windows System font", "extended ASCII", or "8-bit ASCII" -- not going to get into a history lesson here).

The character encoding is a single byte per character, so if we break the string down into its raw bytes, we get:

0x4b = K
0x49 = I
0x32 = 2
0x34 = 4
0x35 = 5
0x35 = 5
0x30 = 0
0x30 = 0
0x55 = U
0x44 = D
0x32 = 2
0x34 = 4
0x30 = 0
0x44 = D
0x47 = G
0x4e = N
0xb0 =
0x44 = D
0xf2 =
0x1b =

This is the serial number string which the actual SSD returns when requested via an ATA IDENTIFY DEVICE command (0xec). We'll get to that in a moment.

The Intel option ROM for your motherboard -- version 7.5.0.1017 -- is provided as part of your PC BIOS (yes, the same BIOS images you download from the manufacturer's website). Intel provides the motherboard manufacturer with this option ROM when they request it. I can tell you right now there are newer version of the option ROM than what your motherboard manufacturer is using in that PC BIOS release, but good luck getting them to update it -- the motherboard manufacturers don't always run "the latest and greatest" stuff, and that's often intentional.

Option ROMs contain standard x86 code like anything else (I'll get to why that matters in a moment too). These option ROMs, given what they do, have to probe the ATA bus for all attached devices -- and in doing so/finding a device during enumeration, they submit the ATA IDENTIFY DEVICE command to the underlying disk (or if CD/DVD, the relevant ATAPI command equivalent).

Per T13/1699-D revision 4a spec (circa May 2007) section 7.16.2, the ATA IDENTIFY DEVICE command response block is 256 word (512 bytes); normal for ATA. Word offsets 10 through 19 (which equates to 20 bytes) contain the serial number of the device, as an ASCII string. The length of the field is static/fixed, not variable. See attached screenshot of section 7.16.7 for that fact.

Section 7.16.2 clearly states, quote:

quote:
Some parameters are defined as ASCII strings. ASCII strings are a list of values that range from 20h to 7Eh which the host should interpret ASCII Characters. Values 00h-1Fh and values 7Fh-FFh shall not appear in ASCII strings.
So at a glance it appears that Intel, with that firmware version on that SSD, is not complying with the aforementioned revision of the ATA specification. However, which specification they're complying with matters -- earlier revisions of ATA8-ACS actually define the permitted characters in this field slightly differently. You're not going to get a straight answer out of anyone at Intel Technical Support about this -- this is straight up an engineering-oriented question/issue.

You see, a lot of option ROMs, BIOSes, utilities, or any other thing, often have code in them that treats these regions (serial number, model number, etc.) in a special way. The specification clearly states 10 words (20 bytes); however earlier specifications stated that vendors are supposed to "pad out" the strings with spaces, i.e. the string "HELLO BOB" would need to contain 11 spaces at the end.

To enforce this, a lot of code tends to do things like strip trailing spaces off the end of the model/serial/firmware strings from ATA IDENTIFY DEVICE, stop processing the string if they encounter a NULL (0x00) (i.e. treat it as end-of-string), or stop processing the string if they encounter a byte that is outside of the permitted range (permitted: 0x20 to 0x7e). This is done solely to keep "garbage characters" from showing up.

In turn, what this has done is create a problem -- engineers/developers writing the firmware code for these disks/devices then begin trying to make use of the extra "crap" at the end of the strings. Sometimes they stick some non-ASCII data at the end to represent something internal -- it could be a checksum value, it could be the build date of the firmware, it could be the score the programmer got at Pac-Man last week. (They shouldn't be doing this, but many do -- bad assumptions and not following specification...) Others do the same but actually pad out the string with spaces and ensure their "special data" is within the permitted range -- for example, my LiteOn DVD drive returns "iHAS524____B" (although that means "revision B", and the underscores are spaces). I'm sure you've seen some hard disks in the Device Manager show up as things like "FUJ9391______CB" (again, underscores=spaces) before. A different revision of ATA specification actually demands that you space-pad your strings. However, like I said, some option ROMs and code do things like cease printing after the first NULL (0x00), so the programmers think: oh okay, I can use the string "BOB", followed by a NULL, then I have 16 bytes left over for whatever I want! Wrong -- but they do it anyway.

Now back to the option ROM. The Intel option ROM, rather than try to avoid printing the gobbledegook, is choosing to display all 20 bytes. They're assuming that all underlying devices are complying with the ATA specification that the bytes contained within the serial number area must be between 0x20-0x7e. And that's perfectly fine for them to do -- the "crux" of the issue is that Intel, on that model of SSD, did not properly follow ATA specification by using only bytes 0x20-0x7e in the string. There may be an SSD firmware update that addresses this, but at the same time, I can assure you that there is a newer version of the Intel option ROM (and no you cannot get it :P) for the ICH9R that stops display of the string once it encounters a byte in a non-permitted range.

I told you it was technical, and I told you it washarmless/cosmetic.
--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.


disconnected

@snet.net

Thank you for explaining the inner workings of how this string is read and reported. Based on that information, I can understand why it's of no concern.

Let me explain a bit about the history of this PC, as it may lend some light on what happened here.
I assembled it in 2007. Original config was Gigaby GA P35-DQ1 rev 1 motherboard, 4GB Mushkin enhanced 4-4-4-12 timings memory, GeForce 8800GTS graphics card and Turtle Beach Montego DDL-II audio card. CPU is an Intel Core2 Quad 6600 (normal clock 2.4GHz)
Back in late 2007 or early 2008, I needed more rendering speed for video projects that were taking overnight to render. So I investigated overclocking options. The stress wasn't on the motherboard so much as the CPU, as the board was designed to go past 4GHz with faster CPUs and was also designed to be overclocked.

I'd managed to achieve a 3.8GHz overclock, but backed it off to 3.5GHz just for long-term stability. My testing tools were Prime 95 and Memtest86. Up to now, that configuration ran beautifully. Recently, I upgraded to Windows 7 64-bit, and a friend of mine kept pressuring me to add more RAM, although I was finding that 4GB was enough to run all my Adobe CS3 apps without any problems or strain whatsoever. But I figured, there's two empty slots, so I'll buy a kit of 8GB and replace the two 2GB Mushkin with four G-Skill sticks. However, the G-Skill, though it also specs as 4-4-4-12 timing, failed Memtest86 at the current voltage settings that the Mushkin were happy at. So I upped the memory voltage +.05V and that seemed okay. Booted Windows and ran WEI. Scored LOWER with this RAM than with the old RAM, so I assumed I needed to do some tweaking of the timings to get the speeds back to what I was getting with the Mushkin sticks. As it turns out, a number of timings were too aggressive and the motherboard is designed to restart and kick back to default safe settings. If it reboots too many times, as in me hitting hardware reset during POST on 3 successive restarts, DualBIOS will assume I flashed the BIOS with a bad / corrupted flash and switch over to the backup BIOS. Now this BIOS was at F8, while the current BIOS version is F9. As a result, I decided to update this BIOS so that BOTH BIOS copies in ROM would be the latest version. Once that happened, my SSD drive began to display those junk characters after the s/n, not before the BIOS update. That's what my original question was about, actually.
Before the experiments with adjusting the new RAM to higher timings, the drives' s/n was not displaying those >127 ASCII symbols. But at least now I understand there's no reason to be concerned. Certainly, the system has never run this nicely in the 5 years I've been using it. SSD, coupled with a 64-bit OS, added speed and stability I have not seen since my days with the SPARCStation II running Sun OS 4.1 (1987). Even when I got my Mac Quadra 950 in the early 1990s, I didn't enjoy that kind of stability, nor with Windows 95, NT, 2K or XP (though XP was coming close). So far, I have been doing ridiculous things on purpose, in an attempt to crash my editing apps, or see if the OS will crash. With Photoshop, Premiere, AfterEffects, Maya, Illustrator, InDesign, SoundForge and Remote Desktop all loaded, the system doesn't break a sweat switching from one to the other, nor do the apps themselves complain. Under this absurd environment, they run better than if they had the whole system to themselves, one app at a time, under XP. I'm actually VERY pleased with the system's operational stability now and would not change a thing.