Latest working kernel version:2.6.23.17 Earliest failing kernel version: 2.6.24.1 Distribution: Ubuntu Hardware Environment: Custom PC with Abit KN9 motherboard, nForce 4 chipset, and 2 SATA Western Digital hard drives Software Environment: Problem Description: Kernels later than and including 2.6.24 no longer detect 2 internal Western Digital SATA hard drives, both WD1600JS-62M, returning a "SEMB device ignored" message on startup. However, a Cavalry external hard drive using eSATA and a Western Digital WD5000AACS-0 hard drive is detected. All drives utilize libata and sata_nv drivers. Kernel version 2.6.23 used libata version 2.21 and sata_nv version 3.5, while 2.6.24 and later use libata version 3.0 and sata_nv version 3.5 Steps to reproduce: 1. Compile a 2.6.24 kernel on an Abit KN9 motherboard using a Nvidia nForce 4 chipset, also known as CK804, with 2 internal SATA Western Digital hard drives and an external SATA Western Digital hard drive, with Linux being installed on the external hard drive. 2. Start Linux. 3. Linux will start, however neither of the internal drives will be detected.
Created attachment 17827 [details] Dmesg output for kernel version 2.6.23
Created attachment 17828 [details] Dmesg output for kernel version 2.6.24
Can you please try 2.6.26.5? Thanks.
Still the same problem. I've also tried pre-patch versions 2.6.27-rc5 and rc6, with the same results. I'll admit right now I know barely anything about how drivers are written, but I did notice that kernels that use libata 2.21 work fine, and later kernels that use libata 3.00 do not work, so that has been my hypothesis, but again, I'm not an expert or anything.
Created attachment 17842 [details] SEMB-sig-debug.patch Can you please try the attached patch? Thanks.
Attempting to install the patch gave me this: test@test-desktop:~$ sudo patch < /usr/src/SEMB-sig-debug.patch can't find file to patch at input line 5 Perhaps you should have used the -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c |index 5ba96c5..b58c2c3 100644 |--- a/drivers/ata/libata-core.c |+++ b/drivers/ata/libata-core.c -------------------------- File to patch:
Ok, correction, I was trying to patch my currently running kernel, silly me. I was able to patch and recompile, and it worked like a charm! On one other note, is it possible that a permanent fix can be merged into the main kernel, so it won't be a constant process of patching and recompiling every time a new kernel comes out? Anyway, it seems to work just fine, thanks a bunch!
Can you please post the boot log from the patched kernel? I'm surely gonna merge the fix upstream but I first need to find out what's going on. Your controller probably is reporting SEMB signature for ATA devices and that's why the detection got broken. I hope this is from the controller not the drive. The drives are directly connected to the connectors, right? Does your board have some special IO feature - say integrated PMP or hardware RAID, etc...?
Created attachment 17859 [details] Dmesg output post-patch My drives are all plugged directly into the motherboard. I'm also not running any special IO features.
Can you please try to connect a different drive and see whether the SEMB message is triggered? This is the first report of this problem and I hope it's caused by the controller instead of the drive. Thanks.
It may be unrelated, but I have been fighting a problem installing Ubuntu on the Western Digital Caviar SE WD1600AAJS. While I had no trouble detecting the drive, I couldn't install any of the following: Ubuntu Intrepid A6, Fedora 10B, Arch or Xubuntu. All failed with similar symptoms at partition time. I had the same problem with two separate drives of this model. I just successfully installed Intrepid A6 on a Hitachi drive. Please see the following for syslog and partman logs: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/276558
(In reply to comment #10) > Can you please try to connect a different drive and see whether the SEMB > message is triggered? This is the first report of this problem and I hope > it's > caused by the controller instead of the drive. Thanks. > Unfortunately, I don't have access to another SATA hard drive, but several months ago, I tried a Ubuntu 8.04 LiveCD on a friend's machine, using a 2.6.24 kernel, and it also returned the same kind of error. I'm not sure what kind of chipset it uses, but I do know it was a Maxtor hard drive.
a SEMB device ignored error, that is
How do you know it was a SEMB problem? There are myriads of different ways hard drive detection can go wrong and this is the first one reporting SEMB problem, so I doubt it's a wide spread problem. Is it possible for you to take out the hard drive and bring it to another machine with different chipset and see whether the same problem exists? Thanks.
drhaun88, your drive is aborting every IO commands it's receiving. Looks like a dying drive to me? Is the drive usable? Can you please boot a live CD and run "smartctl -a /dev/sdX" and report the result?
(In reply to comment #14) > How do you know it was a SEMB problem? There are myriads of different ways > hard drive detection can go wrong and this is the first one reporting SEMB > problem, so I doubt it's a wide spread problem. Is it possible for you to > take > out the hard drive and bring it to another machine with different chipset and > see whether the same problem exists? > > Thanks. > I was able to borrow a hard drive from a friend, a 750GB SATA II Samsung HD753LJ, which was read just fine by a LiveCD using a 2.6.24 kernel. I'm also attaching the Dmesg output as well.
Created attachment 18216 [details] Ubuntu LiveCD with Samsung hard drive
(In reply to comment #15) > drhaun88, your drive is aborting every IO commands it's receiving. Looks > like > a dying drive to me? Is the drive usable? Can you please boot a live CD and > run "smartctl -a /dev/sdX" and report the result? > I ran a self-test on one of my hard drives, and and attached are the results. I don't think my drives are dying, however. They don't make any abnormal noises, and they work nearly flawlessly with my current Windows and Linux installs. The only symptom I've noticed is that they won't be read by any Linux kernel later than and including version 2.6.24
Created attachment 18219 [details] Smart test result
(In reply to comment #18) > (In reply to comment #15) > > drhaun88, your drive is aborting every IO commands it's receiving. Looks > like > > a dying drive to me? Is the drive usable? Can you please boot a live CD > and > > run "smartctl -a /dev/sdX" and report the result? > > > > I ran a self-test on one of my hard drives, and and attached are the results. > I > don't think my drives are dying, however. They don't make any abnormal > noises, > and they work nearly flawlessly with my current Windows and Linux installs. > The > only symptom I've noticed is that they won't be read by any Linux kernel > later > than and including version 2.6.24 Aieee... That comment (#15) was directed at Lon Ingram. Sorry about the confusion.
Can you please post the result of "lspci -nn"?
I've already RMAed both drives, unfortunately. As I mentioned above and in the Ubuntu bug, I experienced the exact same symptoms on two identical, brand-new drives. Neither drive was usable on any distro that I tried.
Can you please still post the result of "lspci -nn"?
Created attachment 18228 [details] results of lspci -nn
Aieee... I was asking drhaun this time. :-) Anyways, I agree those drives should have been RMAed, so did you get drives of different model or ones of the same model?
(In reply to comment #25) > Aieee... I was asking drhaun this time. :-) Anyways, I agree those drives > should have been RMAed, so did you get drives of different model or ones of > the > same model? > I picked up a Hitachi at Fry's and installed Ubuntu and Fedora 10b on it with no problem. I'll probably get another of those. I don't plan to buy that model of WD again.
Created attachment 18231 [details] lspci -nn output Here's my lspci -nn output
Thanks. It seems the drive is reporting 69/96 signature for some reason. I'll ask around. Thanks.
Oops, make that 3c/c3.
Any chance you can sell the drive to me so that I can play with it myself? I wanna try it on different controllers. I can pay for the shipping cost + replacement cost via paypal. Thanks.
(In reply to comment #30) > Any chance you can sell the drive to me so that I can play with it myself? I > wanna try it on different controllers. I can pay for the shipping cost + > replacement cost via paypal. Thanks. > Possibly. I've actually got 2 of the drives. I'd be willing to sell you both of them, since if I kept one, Linux wouldn't be able to read off of it anyway. It might be a bit, since I'd have to order the drive and find the time to reinstall everything. My other question would be one of price. They were about $60 each when I bought them 2 years ago. I'd be looking at a 320GB replacement, which would be about $60, so might $60 for both drives be reasonable?
i´ve the same problem.
Yeap, $60 + shipping sounds fair enough. I'll send my shipping address to you via email. Thanks.
(In reply to comment #33) > Yeap, $60 + shipping sounds fair enough. I'll send my shipping address to > you > via email. Thanks. > Ok, I'll send it off as soon as I can. It probably might be a bit, though, since I still have to buy a replacement hard drive and transfer all my data, but I shall do so as quickly as possible.
I have four WD SATA hard disks (WD2500AAJS) that exhibit the "SEMB device ignored" problem. If I change the code to return ATA_DEV_ATA, the disks work. Other SATA disks do work, using the same controller (on motherboard), and even the same cables, so I assume it is not the controller but the disks. I'd be glad to provide additional testing or information, since I really want these disks to work.
Created attachment 20831 [details] lspci -nn output (Asus P5K motherboard)
Created attachment 20970 [details] libata-workaround-semb-sig.patch.eml The attached patch works around the problem. Patch posted upstream.
Resolving as CODE_FIX. Thanks.
Created attachment 20986 [details] libata-workaround-semb-sig.patch The patch had a stupid bug. Updated version attached.
The patch works, and (some variant of it) has been included in the Ubuntu jaunty-proposed kernel, which I'm running on my desktop.