I got a SATA(3) solid state drive as a gift, so I tried to put it into the system. I only have one machine with a sata interface, and it works fine already with 2 sata drives and 2 pata drives in the system. With this new sata drive attached to the sata interface, the boot-up sequence hangs, giving a message that ends with "doesn't support DPO or FUA" It doesn't say whether it's the drive or the interface or the code that doesn't support those. The last few lines have to do with assigning this drive to be sda. This hang occurs both with the installed Slack 13.37 system and when trying to boot with the installation CD. WinXP boots fine, and I could use it to partition the new drive and format the partitions.

Well, the "doesn't support DPO or FUA" bit isn't the problem; my dmesg output has the same thing.

Now, I don't know about you, but I normally use sda as my boot drive (since it's the first scsi drive of them all). Could you give us the first part of your boot logs when you don't have the SSD installed?

I'm attaching a portion of dmesg as a txt file. Well I see that the same message occurs several times during the successful boot. The system is on the primary master IDE drive, which shows up as sde. Once upon a time it was known as hda when I only had IDE drives. When the new drive is connected, it is assigned to be sda, so if booting were successful, all the other drives would have new names. It doesn't get far enough to attempt to mount the root partition, which of course will need to be changed in /etc/fstab.

Attached Files

bootmsg.txt (4.3 KB, 34 views)

The BIOS controls the order in which devices are numbered. Usually there is an option (or something similar) to order SATA before/after IDE.

Situations like this is why some people use dev by uuid, and other distros set things up with dev by uuid by default. This negates the problems BIOS device ordering creates. Each drive has a unique UUID, and the OS does not care if it's /dev/sda1 or /dev/sdZ1 as the UUID stays the same.

You'll need to figure out how your BIOS decided to remap your drives, and pass the correct root=/dev/sd? at the lilo prompt. Enter recovery mode, remount / as rw ( mount -o remount,rw / ), edit fstab and lilo, write the changes, cross your fingers and reboot

Never mind the drive-name-debacle for now. The workarounds are manageable if a bit annoying (it tries to make you format the wrong partition just like Windows).

The problem is that the kernel in 13.37 hangs right after the boot messages show 4 or 5 lines about setting up the new drive as sda. The last thing printed is "doesn't support DPO or FUA". The same thing happens whether I try to boot the already-installed system or the installation CD.

More symptoms since last time:
1) I removed all hard drives except the SSD; Same result.
2) The installation CD for Slack 13.1 hangs also, but in this case, it starts to print one more line with only "sda:" on that line.
3) The installation CD for Slack 12.0 boots normally. With the setup system running, I can mount the windows partitions on the SSD and read files, and so on.
4) I have a Ghost'ed image of WinXP in parttion 1 of the SSD, and it boots and sort-of runs, but almost nothing works because it makes it's own partition drive H:, leaving no drive C: on the system. All the apps still look for their fragments in drive C:

In Slack 12, the IDE drives are all hda, hdb, ..., and all sata drives are sda, sdb, ...
In Slack 13, both IDE and sata drives are sda, sdb, ...
So there was obviously a change of code in there someplace.

Hi,

Other members have identified your problem and you did not accept their answer, so;

libata_switchover HOWTO <- 'libata_switchover' has been around since 13.0 but some new users are not aware. A new user should look at rworkman's 'libata_switchover HOWTO' to understand and be aware of the changes when using Slackware 13.0 & Slackware 13.1. Especially when performing upgrades or introduction to Slackware 13/13.1.

Hmmm... Nobody has addressed my problem or even mused about it. I restated the problem in my last post because it seemed as if some readers thought that the subject was drive names. The change in drive naming that took place between 13.0 and 13.1 indicates that there was much change of code, which in all probability introduced a bug causing the hang during booting. That HOWTO is vitally helpful to those interested in upgrading (without re-installing) from 13.0 to the next kernel in -current. The mention of drive names only got into the thread because the first reply was curious about it.

I do not upgrade any more because of my abysmally slow internet connection (satellite). I have a subscription for the CD's and I reinstall nowadays. I followed -current from the time that "a.out" executables were replaced with "elf" until version 12.0, and didn't have to reinstall during that time.

Yes, something changed. All drives are now identified as sd[x]. The old way of using both hd[x] and sd[x] no longer exists in most distros, including Slackware.

You stated in your original post that you are using 13.37. That release is using the libata drivers and all drives in your system will be identified as sd[x]. There will no references to hd[x]. Yes, even IDE drives are now sd[x].

With that said, disturbed1 touched upon some things to consider.

First investigate your BIOS. Ensure the drives are listed in the order you want to boot.

Another thing you can do is ensure the drives are connected physically to the SATA ports in the order you want.

If you don't want to fiddle with the physical port order, then as disturbed1 mentioned, you will need to use UUIDs in /etc/fstab to distinguish your drives.

Well, the bug is between your ears. You are still thinking in terms of the old way with hd[x] assignments that no longer exist. So edit your boot loader to use sd[x] and address the boot order issue as described. Thereafter you should be chirping like Tweety Bird.

If I understand correctly, the problem is that the solid state drive does not work with Slackware 13.37. It could be that your SATA controller is not compatible with that brand of SATA drive. Also, check your BIOS settings to make sure the SATA controller is set to AHCI mode and not some other mode like Compatibility, IDE or RAID. Since you use IDE and SATA, make sure that the IDE and SATA controller are not trying to share an interrupt request level.

Hi,

Yes the problem was addressed but not explained clearly. You should read libata_switchover HOWTO
to understand why you are experiencing this issue and how to solve it.

Prior to the libata switch over (which is when the older (since depreciated) access modules where used by the kernel) the SSD drive on your SATA controller works as expected.

After the libata switch over (which is when the older access modules where removed from the kernel, as upstream depreciated them), the SSD drive on your SATA controller does not function correctly.

Make sure AHCI is enable in the BIOS. If AHCI is not an option, it might listed as Native, or something else. If there is not an AHCI option, this means your controller is non AHCI complaint <-- food to feed Google

Several motherboards use 2 different SATA controllers. Perhaps one of your controllers is buggy, not well supported .... try a different port.

If your SATA controller is older, it might be only SATA I (1.5Gps). The SSD might have to be set for this mode. Yes I know, that's not what the specs say, the reality is that some chipsets just do not function that well. My nf3 250 motherboards do not work properly with Samsung F1 RAID version 1TiB drives if the drives are set to SATA II mode. The same controller works fine with Samsung F1 RAID version 500GiB drives with out needing to switch the drives link speed.

I'd guess your problems are somewhere with one of these --- SATA controller chipset compatibility with the SSD and or kernel module. BIOS settings need massaged. SSD firmware incompatibility. Buggy libata code.

for Woodsman:
The drive naming, drive ordering, and boot loaders are irrelevant to the problem. The boot loader loaded the kernel or I would not be seeing the kernel hang half way through its setup activities. Handling those things is similar to when you move cloned systems from box to box, and I've been doing that for nearly 2 decades. I wrote my own boot loader to use when lilo fails. It was useful back in the days when there were many bios schemes to cope with the >1024 cylinder problem, often defeating lilo.

The point is that the kernel in 13.37 hangs if this SSD is connected to the SATA interface. This occurs way before it matters what is on the drive and way before the process worries about where the root partition is. It hangs if the SSD is the only drive connected, and it hangs if there are lots of drives connected.


for Erik_FL:
<If I understand correctly, the problem is that the solid state drive does not work with Slackware 13.37>
Exactly. I don't know why people keep talking about boot loaders and drive naming. I just observed that the change in naming must have required enough code change that one could suspect that a bug was introduced.

<It could be that your SATA controller is not compatible with that brand of SATA drive>
Maybe; also, the SSD is sata(3) and the 2 sata hard drives are sata(2); still, they work together nicely in Slack 12 and WinXP.

<Also, check your BIOS settings...>
This MB has 2 drive controllers, one VIA and one Promise. Both are sata(1); the VIA controller requires the sata drives to be jumpered down to sata(1), while the Pomise does not. The 2 hard drives have such jumpers, and the SSD does not, so I use it on the Promise controller. Both controllers have 2 sata ports each. The VIA has 2 IDE ports, while the Promise has one IDE port. In the bios there is a setting for the Promise device to select Raid or non-Raid. There is nothing like that for the VIA controller; it starts as non-raid, and you have to go into the setup utility to configure raid.

<check IRQ's>
Hmm... I'm not sure I can do that in the case where the kernel hangs. There's only one screen of information, and it behaves the same whether it's full of drives or just has the SSD and nothing else. PCI connected things normally work with shared IRQ's anyway.


Well I thought this was such a visible happening that others would have seen it and say that it's been fixed in such-and-such kernel. I've been with Slackware since 2.2, and this is the first time that I've been stumped (ok, I'm not counting printers). I think this may be my very first time posting a help message. I used to give a lot of help with booting matters back around 1996. I hit a couple other show-stoppers in 13.37, but I solved those without having to post. One of those was that my ddns was broken by 13.37 after working correctly and untouched for over 8 years.

Since libata uses SCSI emulation to manage the drives, you could attach the drive to a running system and issue (as root) a command similar to where the bolded portion of the command are replaced with the host, channel, id, and lun of the new drive. (The command would be the same except for the bolded portion.) I doubt that would actually work, but you might be able to get better error messages. Bear in mind that it might also lock up your system.

I've done that with my system several times, but I also have something similar to one of these to hold my drives, which reduces my chances of screwing up some other component of my system while swapping/adding drives.

Hi,
Picture has changed and becoming a little clearer. More information about controllers in place. It would be nice if you provided the whole output of 'dmesg' to help aid in diagnosis. You state that 12.1 works with drives. What are the specifics for that kernel and drivers? Sample of 12.1 'dmesg' for the information for controllers and drives?Does the kernel OOP out? What about the drivers for your controllers in place? Legacy or new drivers??

What about trying a LiveCD and seeing how the hardware is recognized? What do you see for hardware with the install media?

I have some suggestions that you may want to consider.

Test using another recent distro such as Ubuntu. Do you have the same problem? If not, you can compare the kernel and driver versions. You can also compare source files to check for patches or changes. If you can get an older release of another distro, test that to see if it also works like the older version of Slackware.

Contact the technical support for the drive manufacturer. They might be aware of Linux issues or problems with the drive hanging the system. You could also contact the motherboard manufacturer's support, or possibly support for the controller chips. Chip manufacturers depend on the motherboard manufacturer for support and they might not provide support directly to individuals.

Disable (or don't use) the IDE functionality of the SATA controller where you connect the drive. That will eliminate some possible issues with two drivers interacting. On some combination controllers I've had problems with using both IDE and SATA. IDE tends to use edge triggered interrupts and SATA (being PCI) tends to use level triggered interrupts. The interrupt controller can only be programmed one way (edge or level). Only level triggered interrupts can be shared on the same request level. I've found that the newer versions of Linux drivers work better in that regard because they don't have two totally different drivers for IDE versus SATA. There still might be an issue with some drivers or hardware.

Test on a completely different system with SATA. See if you get the same results with the same distro versions. If you get the same results on a different SATA controller and system then the problem is more likely to be the drive and not the driver or SATA controller. If the drive works on a different SATA controller and system using the same Slackware release then focus on the SATA controller and driver. I've been fighting with a SATA problem on my ASUS P6T mainboard, and both SATA controllers on the mainboard have the same problem. I solved the problem by installing a SATA controller card. My point is not to make too many assumptions from testing on only two SATA controllers in the same system.

If the drive appears to be working on Windows and Slackware 12, try copying some very large files, and try copying a large number of very small files. Verify that you aren't getting I/O errors or unexpected behavior. The same hardware problem can cause different symptoms with different OS and driver versions.

Have you tested the drive after completely wiping the partition table and first 100 or so sectors of the drive? Does it hang with no partition table on the drive? Does it hang if you create the partitions on the drive using "fdisk" in Slackware 13.37?

Are you sure that you're not using Windows dynamic disk formatting? To read the disk from Linux it has to be a basic disk in Windows.

Is your hard disk using GPT (GUID Partition Table) format? Windows 7 and the 64-bit version of Windows XP can access GPT disks. Slackware 13.37 should be able to access GPT disks. Still, you might want to use the older MBR partition table format since it has been supported longer. You could be having a problem with an incorrect GPT. Slackware 12 might see the protective MBR and Slackware 13.37 might try to use the GPT information.

Do you have left over RAID metadata on the drive? That could happen if you connected the drive to a SATA controller set to RAID mode.

Can you return and exchange the solid state drive for a replacement? At least you would be able to test with a different drive to make sure you didn't just get a bad drive. It's possible that the newer drivers in Linux are using commands or transfer modes that older versions don't use. The drive might have a problem.

Have you tried waiting for a very long time when the system appears to hang? I've had some problems where a drive is slow to respond or I/O is being retried. The system may appear to hang, but then later continue. That might give you some additional error messages or allow you to do more testing when the system finally comes up.

Decide how much time and effort you want to invest in solving the problem. At some point it may be better to start using what works and try again later. Not every problem gets solved quickly. It can be frustrating but you might have to wait for newer releases of drivers or more information. I've had a few problems like that with Promise controllers and fake hardware RAID controllers.

It will be helpful if you can post some more details about your hardware.

What is the exact manufacturer and model of solid state SATA drive that is causing the problem?
What is the manufacturer and model of the mainboard (or computer model)?
What are the exact IDE/SATA controller chips in the system?

You can find out the controller information using the "lspci" command in Linux, or you may be able to find the information in the Windows device manager.

2 members found this post helpful.