On Tuesday 20 February 2007, Greg Freemyer wrote: [...]

I think there is some basic confusion about the vanilla kernel.

Libata has been around forever (ie. since sata support started I believe).

As of 2.6.19 Libata added "experimental" support for a number of PATA devices using the /dev/sda nomenclature.

Distros are still advised to use the traditional ide drivers via /dev/hda. This is not likely to change anytime soon, but I have seen that one specific driver in one specific architecture submitted a patch to change the default to the libata version.

FYI: Changing from one set to the other is a basic kernel issue. A specific IDE interface can only be controlled by one driver at a time so you won't have the ability to access it both ways at the same time. I think you can rmmod / insmod to change, but not if it is your root drive.

So if you have a non-SUSE distro that has already changed they are really pushing the envelope. I will be surprised if even opensuse 10.3 makes the jump. It is just too soon.

Also, when the libata pata drivers get more stable there has been discussion of leaving both /dev/hda and /dev/sda behind. Maybe /dev/disk will be used, but all of that discussion is very preliminary as well.

Greg

Thanks Greg, That helps explain some things a bit more. I'm presently using the 2.6.20 kernel and the CD/DVD drives are in fact labelled for srX in /dev, so that part is true. K3B does in fact see the drives, but I've been unable to get it to work with them except as root. I think part of the problem is k3b, part the programs it uses and partly the new kernel. I'm still working on this problem. Everything else seems to work nicely though, as I've not had any problems mounting, un-mounting or reading any discs. I did find out later that libata has been around a while also. Thanks for the input, Lee -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Tuesday 20 February 2007, Basil Chupin wrote: [...]

Hi Lee,

I would be happier if someone could confirm your logic on this - nobody seems to have even read your post (and your follow-up).

Yesterday I upgraded my 10.2 installation to 10.3 Alpha1 which, as you may know, has the 2.6.20 kernel. I also did a new, clean, install of Alpha1. Neither of these seem to support your findings.

The new, clean install is particularly worrying because it departs totally from what I am used to when it comes to identifying drives. For example, the fstab which was generated by the clean install shows this:

dev/disk/by-id/ata-QUANTUM_FIREBALLlct20_20_552102678031-part1 / ext3 acl,user_xattr 1 1 /dev/disk/by-id/ata-QUANTUM_FIREBALLlct20_20_552102678031-part2 swap swap defaults 0 0 /dev/disk/by-id/ata-QUANTUM_FIREBALLlct20_20_052117040222-part5 swap swap defaults 0 0 proc /proc proc defaults 0 0 sysfs /sys sysfs noauto 0 0 debugfs /sys/kernel/debug debugfs noauto 0 0 usbfs /proc/bus/usb usbfs noauto 0 0 devpts /dev/pts devpts mode=0620,gid=5 0 0 /dev/fd0 /media/floppy auto noauto,user,sync 0 0

Nowhere is there a hdx or sdx appearing. The sudden appearance of device ID number is a bit worrying (seeing as how MS is not on the scene).

When I UPGRADED an existing 10.2 installation, 10.3 Alpha with its 2.6.20 kernel had no troubles in working with the old hdx naming convention and the fstab was left untouched.

HOWEVER, in both instances there was one weird anomaly: in the Control Centre under Hardware the IDE DMA MODE there were NO entries. This list is totally BLANK in both cases as if no devices are present.

Something somewhere is not kosher.

Cheers. ==============

Hi Basil, Your info adds even more questions to the whole thing. I know the way Suse usually attacks things in the fstab now are such that many things don't even appear in it any longer. The optical drives are not shown until they are mounted by the system and then by some "id" number in the "My Computer" icon, so I am not sure how the .20 kernel plays into their scheme. As I mentioned, the SATA drives won't be affected, but many of the optical devices are still PATA, which used the hdXX tags and I don't see any hdXX listings in your above fstab either. Check your Grub menu.lst to see what it has. Instructions I have read on the .19 & .20 kernels elsewhere and with other distributions are where I got my info. In talking with some other users, they seem to confirm these findings. The libata module is of course not new, as I originally thought, but it certainly seems like some other things have changed. I also want to comment about the srX designation. I happened to be looking thru some old notes in early Suse versions and found an old /etc/fstab printout. Guess what? It had sr1 & sr0 designated for the /dev/cdrom & /dev/cdwriter. I thought I remembered something like that earlier. :-) Did you check your /dev directory to see if there were some srX devices there in your 10.3 setup? They may not even appear there or be needed now with the automatic mounting system in place? Maybe some kind Suse kernel maintainer will weigh in on the discussion. regards, Lee -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

This is not the same but very well related. You may be able to get some information from the bug I reported: https://bugzilla.novell.com/show_bug.cgi?id=242009 1. IF the ide-scsi binds to the the dvd connected to the ide controller then yes it will become sr0 etc. 2. "ide-scsi is deprecated for cd burning! Use ide-cd and give dev=/dev/hdX as device" 3. K3b will recognize this driver sr0, sr1 etc and it will work..somewhat. It seems that cd works pretty well but dvd burning does not. In summary the cd/dvd functions are not predictable and some do not work at all. 4. I have found no difference with the kernels (2.6 18 and above) except the one that I download when the opensuse developer told me as in the thread above (unfortunately I do not have it anymore). Then from the same place I tried the next iteration and it did not work. 5. In my case the problem is trigger by having another atapi device connected to the ide controller. The position of the device is not important. The only time I can get the ide-cd is to have it disconnected. 6. I wrote to the developer again after I find out that the present kernel still does not stop udev from binding the ide-sci to all the optical disk when the tape drive is connected. As the thread indicated IF the option is enable in the kernel you do not have that problem any more. 7. I have tried to find that option in the kernel but so far I have not been able to find it. If you have any clue please let me know it so I can compile the kernel with the option enable. This has been a real pain and I still can not use SuSE 10.2. and as I said I delete the kernel that worked :-( and the new ones do not work. I wonder what is your setup that triggers the srX for the optical drives connected to the ide controller. -=terry(Denver)=- On Wed, 2007-02-21 at 00:34 +1100, Basil Chupin wrote:

BandiPat wrote:

...

Question!

I'm a bit confused on the new kernels and hard drives, optical devices. According to what I'm reading, any kernel 2.6.19 or above is now using the new libata module for drives. What this does basically is change all devices that were labeled as hdxx to sdxx designation. Is that correct so far?

Now if you have SATA drives, they are already sdxx designated, so no changes are necessary in Grub or Lilo or /etc/fstab. But, if you have anything labeled with hdxx, those must be changed to sdxx to be recognized? Also, if that is correct, what happens to programs like k3b in seeing the drives?

So let's say I have a dual SATA, not counting the Raid, and those will be sda & sdb, right?

Now I have two optical devices, cdwriter, dvdwriter as hdc & hdd presently, so those become sde & sdf now?

sata=sda sata=sdb hda=sdc hdb=sdd hdc=sde hdd=sdf

Is my logic right or do optical devices not count in the whole scheme of things??

thanks, Lee Hi Lee,

I would be happier if someone could confirm your logic on this - nobody seems to have even read your post (and your follow-up).

Yesterday I upgraded my 10.2 installation to 10.3 Alpha1 which, as you may know, has the 2.6.20 kernel. I also did a new, clean, install of Alpha1. Neither of these seem to support your findings.

The new, clean install is particularly worrying because it departs totally from what I am used to when it comes to identifying drives. For example, the fstab which was generated by the clean install shows this:

dev/disk/by-id/ata-QUANTUM_FIREBALLlct20_20_552102678031-part1 / ext3 acl,user_xattr 1 1 /dev/disk/by-id/ata-QUANTUM_FIREBALLlct20_20_552102678031-part2 swap swap defaults 0 0 /dev/disk/by-id/ata-QUANTUM_FIREBALLlct20_20_052117040222-part5 swap swap defaults 0 0 proc /proc proc defaults 0 0 sysfs /sys sysfs noauto 0 0 debugfs /sys/kernel/debug debugfs noauto 0 0 usbfs /proc/bus/usb usbfs noauto 0 0 devpts /dev/pts devpts mode=0620,gid=5 0 0 /dev/fd0 /media/floppy auto noauto,user,sync 0 0

Nowhere is there a hdx or sdx appearing. The sudden appearance of device ID number is a bit worrying (seeing as how MS is not on the scene).

When I UPGRADED an existing 10.2 installation, 10.3 Alpha with its 2.6.20 kernel had no troubles in working with the old hdx naming convention and the fstab was left untouched.

HOWEVER, in both instances there was one weird anomaly: in the Control Centre under Hardware the IDE DMA MODE there were NO entries. This list is totally BLANK in both cases as if no devices are present.

Something somewhere is not kosher.

Cheers.

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org