To reiterate the background on this, the 2.6 kernel has new drivers called PATA drivers for the IDE internal drives in a PC. The main difference from the older IDE drivers is that they use a SCSI-emulation layer and all drive device nodes are /dev/sd* for hard drives, /dev/sr* for optical drives. This is identical naming to other drives that use the SCSI-emulation layer, USB and SATA, as well as real SCSI drives.
The old notion of distinguishing IDE drives by their /dev/hd* device node name is gone, but then it is nice that all optical drives have the same /dev/sr* naming.
Anyway, I thought that the PATA support in the 184.108.40.206 kernel had matured enough and finally we could use it. The Puppy 4.1 alpha series has used this new PATA system, and it seems fine on all the PCs that I have tested on. However, some Puppy-testers do have some mysterious problems, such as Lobster reporting Puppy seizing up after a few minutes on one PC. Also some shutdown issues. Now, it could be that these are due to something else in this new kernel, but we need to go through a process of elimination.
Hence, I have recompiled the kernel with PATA drivers tuned off and the old IDE drivers turned on. In both cases these drivers are built-in to the kernel, not modules, and testing the "IDE kernel" so far all the old modules still work -- in other words, all the current modules and those compiled by tempestuous and anyone else for the 220.127.116.11 kernel should still work.
I am going to upload Puppy 4.1alpha5-with-IDE-kernel tomorrow, and would appreciate if everyone who has tested earlier 4.1's could also give this one a spin. I think everyone should be in this -- after all, if Lobster finds that it fixes his PC, but someone else who previously had no trouble suddenly finds trouble with the IDE kernel, then it's a case of one step forward and one step back.
I will upload tomorrow, approx. 24 hours from now, as have to fix a couple of scripts that I wrote assuming the new PATA devnode naming. Also, I'll be back in Perth, with fast ADSL2 access.
Note, I have added this IDE kernel to the others in Unleashed, so Puppy can be built with quite a choice now.
Comments:Posted on 2 Aug 2008, 18:23 by ANOSage
Recently, I briefly investigated PATA/SATA. It transpires that the SATA specification settled on some fantastic access rate - many Gbs, the actual figure is irrelevant. Irrelevant because the everyone knows that the SATA controller specification is 150Mbs(actual) for SATA1, 300Mbs for SATA2 and ~600Mbs for the imminent SATA3. But even this is irrelevant, because the best drives can only manage 120Mbs which is 10% less than the best PATA specification. Ever been sold a lemon?! The trade is up to their usual tricks.
Notwithstanding, there might be slight benefits accruing from hotplug SATA capability on high end professional HW - just like scsi! Then there's always NCQ - a queuing facility which only a tiny number of professionals understand, and even fewer bother to implement. Anyway, it's all explained on the Net/Wiki.
Thinner cables? Yes, but 'round' cables are already available for PATA and SATA needs more of them to carry sufficient current. Talk of dog's dinner.
Then, of course, as we read on the Forum, some folks have issues with SATA drive booting.
Best stick with PATA and scsi?
Posted on 2 Aug 2008, 18:26 by ANOSage
Was that a typo? Should it be PANTO/SANTA....
Posted on 2 Aug 2008, 21:17 by kirk
One problem with switching back is that DMA will be lost on many newer drives.
Posted on 2 Aug 2008, 22:05 by BarryK
what do you mean? what newer drives?
For SATA drives, the "IDE kernel" is the same as before, still using the libata SATA drivers.
Posted on 2 Aug 2008, 22:35 by Flapdoodle
I am a Puppy user of about 6 weeks now, and have tried 3.01, 4.0, 403, 404, 405. Drives have always been identified as sd* (including flash drives) and I have not seen hd* on any Puppy version either with my SATA PCI card installed or without. However, drives on that card have not been recognized.
All the HDs I have used are UMDA66, with a 80 wire cable.
I did not mention the sd* device node name since it has been on all 3 computers I have tried Puppy on, so I figured that was normal. Is it?
Posted on 3 Aug 2008, 8:44 by kirk
Without the PATA drivers, DMA does not work on my laptop's CD drive (it's connected with a SATA hard drive). Hdparm doesn't help. My drives show up as /dev/hda and /dev/hdc. But I can boot with combined_mode=libata if you use the old ide drivers in the kernel. With combined_mode=libata passed to the kernel I get /dev/sr* instead of /dev/hdc for my CD drive and DMA works. I don't know how many users would know that. If you go with the older drivers, I guess you could put a note on the boot splash screen.
I'm pretty sure the kernel with 3.01 used the old ide drivers. You should have had /dev/hd* for your drives unless you were passing combined_mode=libata to the kernel at boot.
Posted on 3 Aug 2008, 9:04 by Jesse
Which hard disk kernel driver model is right?
How silly/sensible would it be to have the hard disk drivers (old hd*, new sd*) all as modules, with a puppy boot option, maybe 'hdfix' to say 'old' or 'new' or perhaps the specific name of a driver, so that we can choose on an individual computer basis which driver we boot with?
If we need to be able to choose, then perhaps it needs to be a boot option?
Posted on 3 Aug 2008, 17:55 by BarryK
IDE vs PATA
Up to and including 4.00, IDE drives are /dev/hd*.
I'm wondering if we can build the kernel with PATA drivers for some newer IDE drives, IDE drivers for the rest. It won't matter that some IDE drives are then going to be /dev/sd*, some dev/hd*, all my scripts can handle that.
The thing is to decide which ones... I wonder if any other distros have been down that path?
Posted on 3 Aug 2008, 22:21 by dogone
IDE vs PATA
This appears a good source of info on the state of the matter.