Thinkpads Forum

Hello everyone,

I've gotten some really nasty BSODs that are making one OS completely unbootable, and I need to get to the bottom of them. I'll tackle those in another post in the next day or so, after I do some more tracing. Before then, I need to figure out more about the Ultrabay Slim controller for the T61p, to start to establish whether that's the culprit. (I don't want to complicate matters too much in this post.)

I'm looking for clarification on what the controller is in the T61p Ultrabay Slim. Of course, it has a SATA interface, but I have seen offhand remarks (how informed, I can't tell) to the effect that the T61 series has a PATA controller (on the motherboard? or as a translation chipset on the Ultrabay?) underneath the hood of its SATA connector.

Technically, can someone explain whether this is actually possible?

Here are the vague hints I've read:

And can you speculate as to how Vista would behave if it were built in the HHD 0 slot, in a SATA BIOS setting of AHCI, and then booted though the Ultrabay, and possibly swapped back to HDD 0? (I'm not sure that's what's caused my (unfixable) problem, which I'll detail elsewhere, but I want to know more about the Ultrabay interface first.)

From Matt Kohut, talking about the W700:

There’s an Ultrabay, and yes it will support a 3rd drive. It’s our new SATA based Ultrabay rather than the old PATA Ultrabay.

http://lenovoblogs.com/insidethebox/?p= ... ment-51849

From christopher_wolf, referring to part 40Y8725, a later Ultrabay for the T60p:

The SATA ultrabay that GomJabbar posted a link to is different and appears to be for SATA HDDs only; which means there are now two 2nd HDD Ultrabay adapters for the T60. Ones that are PATA supported and ones that are SATA supported. Both appear to use EIDE in the end-connector to the Thinkpad.

http://forum.thinkpads.com/viewtopic.ph ... 71#p162950

From a thread over in NotebookReview:

The old bay connection [on the T61p] supported both SATA/PATA/legacy, and the new one [on the W500] has an entirely different connector.

http://forum.notebookreview.com/showthread.php?t=288779

From comptiger5000:

The W500 and other new thinkpads have a SATA ultrabay, so any previous device (batteries excluded) will not work, even if it fits. The T6x and prior had PATA ultrabay connections.

http://forum.thinkpads.com/viewtopic.ph ... 7b#p466676

If there is documentation or a hardware explanation of this -- How did everyone figure this out? -- please do me a huge favor and point me to the info. I need to know what chipset, where, is doing the converting from SATA to PATA, so I know whether this is something I may need to discuss with Lenovo, with Intel, or with Microsoft.

Thank you for the explanation.

a.k.a.

The Intel 965 chipset actually still has PATA support in it. No idea if that is actually what is being used for the Ultrabay.

A.K.A wrote:How did everyone figure this out?

Mostly by looking at the connectors on the relevant UltraBay Slim carriers - no rocket science involved!

Cheers,

Bill B.

T61 Ultrabay SATA HDD enclosure has SATA-to-PATA bridge, and the connection is indeed PATA. At least that's how I understand it.

Bill, for someone with my pint-sized noggin, it's much more complicated than that!

I've been Googling for a diagram of what the different connectors are on the 2.5" HDDs, and the Ultrabays, and I'm not making any sense of them yet.

As far as I can see, the T-series U-Slim isn't a PATA-out. It has a 15-pin SATA Standard Connector.
http://en.wikipedia.org/wiki/Serial_ATA ... _Connector

I did just find an article, also not fully explanatory, that says that SATA is fully PATA compatible.

Although SATA drives are not physically compatible with PATA devices, they support the same standards and as such they can communicate either through software (in your operating system) or with an adaptor like the one pictured below which converts a PATA drive for use with SATA cables.

http://www.hexus.net/content/item.php?item=1339&page=2

I don't know jack about buses, if you'll excuse the pun. But in sum, all I am able to guess is that the conversion into PATA is happening either via the quality of cables inside the TP, or in the motherboard's ICH8M-E/M SATA AHCI Controller.

I have the old Ultrabay 2000 with it's honkin' 2" custom port, and it looks different from the svelte 1" 15-pin. I assumed SATA. I'm easily scammed by these things ...

Although ... just to stick up for myself ... I do have some capacity for discernment. I haven't run out and bought an iPhone. Personally, I much prefer my iBrick, which I modded myself by mis-flashing my Moto. (It can save you A TON on phone bills!)

The 15-pin SATA in the wiki page is for power only. On top of that there is another 7-pin connector for data. Did you see two connectors? And like I said, the ICH8 has PATA support built in, so no conversion is needed.

No, that's what puzzled me at first too. At least with the DVD Multi for the Ultrabay Slim, there's only the 15-pin. (I can't take my HDD bay out right now, but it's got to have the same interface, since this DVD is definitely running over the 15-pin SATA connector, even as (I'm almost positive) it's a PATA device.

The Wiki, in my read of it, is just stating this unclearly. (Why do you need a 15-pin power connector, when a simple jack would do nicely?) I could just be totally off base, but the "power connector" they describe this as is actually the data bus too. If you look further up, it shows that SATA is using a form of differential signalling, that is, voltage-modulated data transfer. I'm not sure how SATA can have all of these different connectors and still work identically, device to device.
http://en.wikipedia.org/wiki/Differential_signaling

Again, I may be missing something, but there's nothing else connecting the DVD Multi to the laptop but the 15-pin, so it's hard for me to imagine the HDD caddy is different.

aaa, can you tell me a little more about the PATA support on the ICH8? Any idea how that operates? It's my impression that that is the crux of the issue.

I've just started a thread over in the General Hardware subforum, to ask people if they have any shred of information about the actual causes of the BSODs that are being seen in the x6x series, and it's my increasingly strong concern that this is actually rooted in an incompatibility between the ICH8M-E and the SATA-to-PATA conversion like you see on the Ultrabay Slim. There are related devices that are all getting BSODs around hot-swappable / hot-mountable PATA I/O operations and the mobile (M or M-E) variants of Intel's ICH8 I/O controller hub. Check out the BSODs among the Dell Precision M4300, for instance -- and it has both an ICH8M-E and a PATA version of what Dell is now calling an Ultrabay. But as there's still no focused discussion, that's going out on a limb, so I'm hoping to learn more before I lay out a possibly half-baked model of when and how the ICH8M-E is getting tripped up.

My frustration is that after 1.5 years, Lenovo, Intel and MS have not made on-the-record statements about the mechanism for this BSOD -- just random workarounds supplied by Lenovo, Intel and MS. Why not? Well, Lenovo seems to have made advertising claims on the Ultrabay interface. Intel, because of the advertising claims around Turbo Memory. And MS, because Vista can't switch comfortably between AHCI and Compatibility without BSODing (KB922976), and they didn't imagine a scenario in which the devices on which the OS is installed switches between protocols. (And, of course, they have reasons not to point out the defects in their hardware partners.) Not to paint with too broad a brush, but conceivably there are M.O.s in each case that could suggest why mum's the word on what has been learned about the defects of these components. They're all more than happy to move on from the ICH8-generation laptops, be completely non-responsive in the forums, and pretend this stuff is "obsolete hardware" already because a newer doo-hickey has come out since. Have you noticed that there's no more PATA backward compatibility in Intel's latest mobile I/O controller hubs? But, this is getting way ahead of gathering the facts.

The thread is here, so if you're reading this, and you know something, please visit that thread and contribute. If you know WHO would know something, please PM or prod them in conversation to contribute.
http://forum.thinkpads.com/viewtopic.php?f=18&t=71823

When I last time connected my SATA harddrive to the SATA controller in desktop computer, I only used the 7-pin data for it. The other one, the 15pin power, went through adapter to an old 4pin molex connector - therefore I highly doubt any data got through that one, unless some wizardry is going on.

If you count the pins on the Ultrabay device, you should reach number higher than 15. Actually higher than 20. Times two - the connector has two sides - and we're at 40+ needed for PATA connection.

There are three connectors in the T61's Ultrabay - one for battery, one for Parallel/Serial port and the third for various drives - DVD, HDD.
The new machines (T400 etc) have finally upgraded the last connector to SATA - rendering all these devices incompatible.

Zender, thanks for that clarification. I'll have to finallycheck the bay for the HDD port configuration. Too busy being obsessed with it to power off and take a look!

The DVD has two rows -- the top row, which is male, is 25 pins, in about as much space as the 15-pin SATA, and they're so small it's almost painful to count. 20 are indents, 5 are bumps.

The bottom row is female, and I am not going to bother to count the bumps.

Your point is well taken, then! It certainly has enough connectors to get to PATA.

Is this another "custom" port jobbie like the Ultrabay 2000? Or is it a standard interface of some kind? It doesn't matter now. Just curious.

Do you know if the T400 actually has a SATA-based Ultrabay DVD? Or is it still converting over from PATA?

Thanks for the info!

a.ka.

I think the T400 and other new models have SATA Ultrabay. Which is why the Ultrabay device compatibility that was maintained throughout the T60 and T40 series breaks with the T400/T500/W500.

That's what I thought.

Important follow up: Is there any record of instability right now in the "hundred" series?

Thanks!

"I did just find an article, also not fully explanatory, that says that SATA is fully PATA compatible."
No, I think you are misreading the quote. What they mean is that ATA drives are ATA drives, and the command strongs to/from the drives should be the same. P-ATA and S-ATA refer to the interface hardware that is added on to the ATA drives--and that's an additional physical layer of hardware which is totally incompatible.

Think of if this way: A cable modem and a DSL modem are "fully compatible" with the internet, and the side that plugs into your computer is that same for each. But, you can't plug a DSL modem into a cable provider's network, and you can't plug a cable modem into your phone line, the hardware is not compatible at all.

On the larger issue: Vista, like any version of NT, creates a hardware-specific boot file plus a profile for your machine (i.e. the HAL.DLL Hardware Abstraction Layer file) and when it boots & loads, it looks for that specific hardware. If you install it to ANY drive, it tracks the drive controllers and the drive assignments (dirve 0, 1, etc.) and it looks for the OS on a specific drive position forever after. If the bay drive is "drive 1" (remember, the first drive is "zero") and that's where you install the OS to, it won't boot/run when you move the drive to the internal fitting, where it becomes "drive zero"!

There are various ways to manually change the boot loader file in different versions of NT, I know Vista changed the rules on that but it should still be similar. In both the problem and solution. And, there are "repair" tools on the retail OS discs that will search the drive(s), located OSes, and fix the boot file to point to them. So it can be done--just quite a bit more than "swap swap" to do it.

Ok, great. This is getting at one of the specific problems I'm finding.

A lot of the BSODs around the Ultrabay HDD have to do with swapping the drive slot. BUT, HDD swapping happens just fine in the T61p in Compatibility Mode -- while they do seem to happen (with varying frequency in my experience) in AHCI. This is an I/O Controller Hub issue, not an OS issue, unless you want to count the associated NAND caches being accessed at boot by Vista (if they are in fact) as being a Vista problem, which certainly did contribute.

Can I ask for a little more basic clarification on how to read Device Manager? When I look at the properties of my HDDs in Device Manager, I see a "location" descriptor as one of the options under the Details tab. In some cases, the location is called "Channel 0." Is the Channel terminology what you've just discussed here (drive 0, 1, etc.)?

And specifically, what's a "conflict" in ICH terms? An ICH may I/O with about how many [slots / channels / locations / whatever]? If Channel / Location is not at the heart of device conflicts, then what should I be looking for under the Details tab to sort out conflicts?

There's a definite conflict, that I'll get to here, but it's a little more subtle than a runtime issue, if I can bandy about some jargon I don't fully understand. The one I've noticed is actually written into the ICH, as far as I can tell. Because,
1) I can see the device conflict in the controller settings even when the BSODing OS is not booted -- and am fairly positive that
2) The controller isn't getting the info out of the OS I'm in, because there aren't any resource conflicts occurring at present -- and also that
3) The controller isn't reading from the non-booted BSOD'ing registry hive for this info -- if it were reading a registry entry, it would be reading if anything from the current OS' registry, where there are no device conflicts, right?

It would be my guess that the ICH is reading the registry from something like an on-board EEPROM setting. And I'm seeing something really odd that looks like it would be the source of the boot BSOD. I'm getting a little ahead of myself, because to check my inferences, I need to understand the basic I/O questions I just asked first.

And finally, this principle differs from IRQ numbers for controllers and chips (under the resources tab) HOW? I guess the CPU can attend to an infinite number of IRQs in theory, because it's not tied to a physical device, just an operation, right?

The reason to learn more about that is that the BSOD error I got was "IRQ_NOT_LESS_OR_EQUAL." Knowing absolutely nothing, my working model is that some devices that got fused into the same channel are sending overlapping info to the CPU, which is having trouble interpreting the info. I don't know how the IRQ numbers fit in here, but I can only take a stab at it....

Here's MS' generic "Sorry, you're on your own" description of this error: "This is a kernel mode crash issue. Generally it occurs when a driver tried to access an address that is pageable (or that is completely invalid) while the IRQL was too high."

In plain English, Microsoft, that means????

Does that mean that the CPU needs to both access a pagefile and process a high-priority request at the same time, and can't do both simultaneously? Still very opaque to the uninitialized ... I mean, uninitiated.

I'm not up to date on all the issues so I can't answer all your questions with certainty.

"Is the Channel terminology what you've just discussed here (drive 0, 1, etc.)?"
No. On a typical motherboard, there are two IDE/ATA controller channels, each ends in one set of pins and you plug a cable onto it. Then you plug either one or two drives into the cable. That would be two 'channels' if they are hung on one controller, and in a laptop motherboard I'd expect only one channel since there is usually only provision for 1-2 drives. The controller has a physical hardware address though, and if you plug in another controller (i.e. a SCSI device on an expansion device) now you have two controllers. The OS will look for the controller with the lowest (highest?) address first, and assign "drive0" to the first possible drive location on that controller. IIRC the OS assignes drive numbers based on the drives that are physically present--not possible, but present. So if you have two drives today, the second one becomes "drive1" (they start counting at zero, classic binary-bound illiterate programmer mistake) and if you try to use it as the solo drive tomorrow--no good, the OS is looking for "drive1" but now there's only a "drive0" installed.

"And specifically, what's a "conflict" in ICH terms?" Dunno. Now that BIOSes can boot from external USB devices, I would expect they also look at the USB bus as a potential drive "channel". Any time that multiple or conflicting devices send back the same information--or conflicting information--because things were moved around, that would probably generate a "conflict" error.

"1) I can see the device conflict in the controller settings even when the BSODing OS is not booted " I'm not sure how or why you are looking at controllers BEFORE the OS loads or crashes, I know nothing about them at the BIOS level--which is all there is to look at before the OS starts loading. But again, it sounds like "swap swap" is leaving something identifying itself as something else (or somewhere else) and computers don't like things being moved around without some warning.

"It would be my guess that the ICH is reading the registry from" Uh, no. Nothing reads the NT Registry except NT. That's for sure. And NT itself enumerates the hardware--bypassing the BIOS--when it does a cold boot.

" I guess the CPU can attend to an infinite number of IRQs in theory, because it's not tied to a physical device, just an operation, right?" Totally wrong. IRQs are hardware address lines, 8 in the old PC's, 16 in the PC/ATs. Beyond that the newer OSes use "interrupt sharing" any AFAIK that's still hardware bound, there are typically two PCI controllers on a desktop motherboard, each controls three slots, but they "share" interrupts because they still know which controller is up to what. Even virtualized devices are going to be limited by the OS as well--there's no such thing as "unlimited" with computers.

"the BSOD error I got was "IRQ_NOT_LESS_OR_EQUAL." Yeah, that mainly translates into "There's a problem with a driver and your hardware". Forget physical IRQs, look at the rest of the message and it usually will give you a hint as to the driver name or the type, i.e. scanner, display, drive.

I'm not really sure what you're after, but it might help you told us what actually happens and not what you think is behind it.

If you use Compatibility mode, the BIOS will emulate that your SATA device is a PATA device. When you change this with OS installed, the OS won't find itself. In Ultrabay, it always is a PATA device (at least I think - I don't have experience here - but please don't scrape that thought just because of that).

Ok, hellosailor and Zender, Bill, aaa, dr_st and others, thank you (I mean that) for listening, writing, and helping get me up to speed on all of this. I owe you, and in deference to that, here it is...

The Interesting Bit!

Well, actually, a smidgeon of background first. Ok, so just hold the ooohs and aaahs.

It turns out that the Intel Turbo Memory Console is a standalone executable. (Most hardware consoles ought to be, because it's too dangerous to have them tweakable in the OS itself.) I found that if I went into the dead OS and launched it, the TMC would actually run. It was just a hunch. Furthermore, Turbo Memory is dead in the OS I'm using now, so it's not reading from Windows at all, as far as I can tell. And under the View --> System Information tab, I had to clean my eyeglasses, because it actually says that my Turbo Memory cache is 93GB in size, and that the "disk cache location" is a Hitachi HDD -- the one that happens to have my dead Vista installation on it. Coincidence? I don't think so.... Weird, huh?

Oh, and by the way, the HDD is NOT a hybrid HDD, and so the TM Console is not talking about a ReadyDrive cache, I'm pretty sure, unless.... well... it's possible that it is saying "there was a cache in Channel 0" and just naming the device that goes in that channel now, which is a Hitachi. Formerly, what resided in the Ultrabay was a Samsung with a hybrid cache, so this could be frozen looking for the Samsung cache. Still, the Samsung has been in the laptop the whole time, so it ought to have figured out at some point where the cache went -- and if it didn't, well, all the more reason it sucks. Furthermore, the cache size on the actually-hybrid Samsung is 93GB? Gimme a break. It's not really looking with any accuracy for an actual cache size on the device it's checking. It's just tracking some generic volume capacity. It doesn't have any earthly clue what manner of device is running at that location, it just claims that's the device it needs.

Anyway, for now, let's talk about ReadyBoost NAND, and say this is a definite channel ID misconfiguration.

I've turned up several other "system information" screendumps that say equally screwy things about the cache being on someone's HDD, one of them with a corrupted volume title too. One of them was saying he got the error message, ""A cache exists on another device in the system. Please remove the cache from that device before creating a cache on this device."

Finally, one of these other Frankenstein device listings was triggering the IRQL_NOT_LESS_OR_EQUAL error too.

In other words, whatever you make of this, it's an IRQL conflict of some kind. And the fact that even though the NAND is currently non-functional from inside the running OS, launching the console from off the dead OS' partition and getting some eye-opening readings from it -- suggests that this reading is being taken off of the ICH's EEPROM, and the EEPROM is corrupted.

I can think of two ways to test that hypothesis:

1) Install the Vista recovery WIM onto a partition on my Samsung, rather than on the Hitachi (plus an EasyBCD multiboot setup so the MBR isn't playing tricks here too.) If Vista boots on the Samsung, then it's a hardware channel conflict, not an off-kilter setting created at runtime by the OS.

2) Run the Intel Chipset Driver Utility, which should "reset" the Intel chipset. If that fixes the problem, and lets Vista boot, then we know it was the EEPROM setting.

If you can project a more foolproof fix, I'm taking notes. But of the two, do you think one or the other would be the more sensible explanatory test?

Now, explaining why the ICH handled it this way (if it did) is a little trickier, and there's a lot of room for contending interpretations. My belief is there's one of two things going on:

a) The ICH has one IDE-emulation channel (for a pair of devices), and somehow it wound up treating the number of IDE I/O devices hooked up to it as >2, so wound up "fusing" two devices. (I mean, why else would the ICH lose complete track of where the Intel flash-cache NAND is? It's not going anywhere! I can understand the HDD, but to spontaneously claim the NAND is now on the HDD device is somewhat counterintuitive. If, as you said, the ICH doesn't just let the devices wander hither and thither and actually tries to get a fix on what is where, then by that logic it wouldn't dare lose track of the NAND.) Explaining how that IDE count increased to >2 is still a mystery to me, unless the inventory was this: 1) FAT32 formatted NAND; 2) DVD Ultrabay, swapped-out; 3) newly swapped-in Ultrabay (false SATA, true IDE) with the HDD in it.

b) Unless... the ICH just has defects when it is trying to juggle both AHCI/NCQ and IDE-emulation simultaneously. I would imagine that a SATA interface HDD running over IDE in the Ultrabay is a real challenge to the MSM's concept of reality. Plus, we have already established that the Matrix Storage Manager (iaNvStor.sys) is implicated, beyond this OS' IRQ wipeout, in problems as wide as the Active Protection System's touchiness and system lock-ups, in random battery-only NCQ-related "hybrid power" lock-ups, and in audio reproduction (Dells) and DVD jitters (in Lenovo on battery). The list goes on, doesn't it? If I were describing it, I'd say the ICH8M-E is looking pretty defective in IDE-emulation ... and that's why 1) no one's coming forward to explain the actual problem or why the fixes offered are supposed to work; why the companies are 2) just treating this generation like it's "obsolete hardware;" why 3) Lenovo is making sure that everyone knows the "hundred series" Ultrabays are true SATA; why 4) Intel completely dropped "PATA compatibility" functions from the subsequent generation of mobile ICHes.

Ok, it's late, I've spun my yarn, and you guys can shred my reasoning tomorrow.

Thanks for sticking with this discussion so long.

Just some rough cuts at a diagnosis would be great. All of you have seen more ThinkPad hardware than me in your career.

I just got told today by Intel that this problem "is related to the motherboard", but the boilerplate reply also suggested that it's Lenovo's responsibility to tell me more.