Merging libata PATA support into the base kernel

Merging libata PATA support into the base kernel

[Alan Cox]

Jeff (rightly) thinks the plan should be discussed publically, so here
is the plan

For 2.6.19 to move the libata drivers to drivers/ata
Add a subset of the new PATA drivers living in -mm to the base kernel

Many of the new libata drivers are already more stable and functional
than the drivers/ide ones. 


What does this mean for end users selecting the existing IDE layer
- Zilch, Nada, Nothing
- No changes in behaviour, no different code paths

For the more adventurous
- Better SATA/PATA integration
- Support for some chipsets not supported by drivers/ide
	(jmicron, newer VIA, mpiix, netcell, efar, etc)
- Active maintainance and updates
- Better quality drivers and error handling
- Inevitably more interesting bugs to find and help fix
- A chance to knock out any bugs and assumptions with other platforms

The new libata PATA support has some caveats at the moment
- No support for certain old serialized devices
- No support for prehistoric CMD640 controllers
- No support for host-protected-area yet
- Drives appear as /dev/sda /dev/sr0 etc along with the libata SATA
devices (and since you can't tell SATA from PATA at times its hard to
avoid). That means people with some older distros wanting to try it
might need to change their fstab or rootdev. People not trying it won't
be affected.

At this point in time it is premature to discuss or plan the point at
which the old IDE layer would go away. That discussion can start at the
point where everyone is happy that the new libata based layer is
providing better quality and coverage than the old one. Even then there
would be no need to hurry.

Alan

Re: Merging libata PATA support into the base kernel

[Mark Lord]

Alan Cox wrote:
> Jeff (rightly) thinks the plan should be discussed publically, so here
> is the plan
> 
> For 2.6.19 to move the libata drivers to drivers/ata
> Add a subset of the new PATA drivers living in -mm to the base kernel
> 
> Many of the new libata drivers are already more stable and functional
> than the drivers/ide ones. 
..
> At this point in time it is premature to discuss or plan the point at
> which the old IDE layer would go away. That discussion can start at the
> point where everyone is happy that the new libata based layer is
> providing better quality and coverage than the old one. Even then there
> would be no need to hurry.

As creator of the ancient IDE subsystem, I agree --> it is time to get
the next generation code upstream.

This will also allow time for things like "udev" to perhaps think about
an option to someday provide /dev/hd* symlinks for PATA devices when
libata is used instead of IDE (?).  That might be a possible migration
path in the far future.

Cheers! 

Re: Merging libata PATA support into the base kernel

[Jeff Garzik]

Mark Lord wrote:
> This will also allow time for things like "udev" to perhaps think about
> an option to someday provide /dev/hd* symlinks for PATA devices when
> libata is used instead of IDE (?).  That might be a possible migration
> path in the far future.

Unfortunately a symlink won't work because of compatibility issues. 
/dev/hd supports more partitions, and a different set of ioctls.

	Jeff

Re: Merging libata PATA support into the base kernel

[Jan Engelhardt]

>> This will also allow time for things like "udev" to perhaps think about
>> an option to someday provide /dev/hd* symlinks for PATA devices when
>> libata is used instead of IDE (?).  That might be a possible migration
>> path in the far future.
>
> Unfortunately a symlink won't work because of compatibility issues. /dev/hd
> supports more partitions, and a different set of ioctls.

I think apps should not rely on the name specifying whether a device is 
IDE/SCSI. After all, udev names like "/by-id/..." don't tell anything 
about device type whatsoever, like "hda"/"sda" do.



Jan Engelhardt
-- 

Re: Merging libata PATA support into the base kernel

[Olaf Hering]

On Thu, Aug 10, 2006 at 02:13:51AM -0400, Jeff Garzik wrote:
> Mark Lord wrote:
> >This will also allow time for things like "udev" to perhaps think about
> >an option to someday provide /dev/hd* symlinks for PATA devices when
> >libata is used instead of IDE (?).  That might be a possible migration
> >path in the far future.
> 
> Unfortunately a symlink won't work because of compatibility issues. 
> /dev/hd supports more partitions, and a different set of ioctls.

Is there a dm-$partition.ko that assigns a bunch of dm-N devices per partition table entry?
Or can all that be done from userland, parsing the on-disk partition table and
create dm-N devices to access everything thats accessible now?

Re: Merging libata PATA support into the base kernel

[Mark Lord]

Jeff Garzik wrote:
> Mark Lord wrote:
>> This will also allow time for things like "udev" to perhaps think about
>> an option to someday provide /dev/hd* symlinks for PATA devices when
>> libata is used instead of IDE (?).  That might be a possible migration
>> path in the far future.
> 
> Unfortunately a symlink won't work because of compatibility issues. 
> /dev/hd supports more partitions, and a different set of ioctls.

Anything that depends upon the extra partitions is going to have a 
difficult time regardless of whether or not they edit /etc/fstab
to change "hda" into "sda" etc..

And libata already has sufficient ioctl compatibility for nearly all
purposes with the old drivers/ide stuff.  Yes, there are some more
esoteric ioctls that I once implemented in drivers/ide that do not
exist for libata, and nobody will miss them.

Cheers

Re: Merging libata PATA support into the base kernel

[Matthieu CASTET]

Hi,

On Fri, 11 Aug 2006 11:47:07 -0400, Mark Lord wrote:

> And libata already has sufficient ioctl compatibility for nearly all
> purposes with the old drivers/ide stuff.  Yes, there are some more
> esoteric ioctls that I once implemented in drivers/ide that do not
> exist for libata, and nobody will miss them.
IRRC, there nothing for ATAPI ioctl compatibility, there only things for
ATA.

Matthieu

Re: Merging libata PATA support into the base kernel

[Tejun Heo]

Matthieu CASTET wrote:
> Hi,
> 
> On Fri, 11 Aug 2006 11:47:07 -0400, Mark Lord wrote:
> 
>> And libata already has sufficient ioctl compatibility for nearly all
>> purposes with the old drivers/ide stuff.  Yes, there are some more
>> esoteric ioctls that I once implemented in drivers/ide that do not
>> exist for libata, and nobody will miss them.
> IRRC, there nothing for ATAPI ioctl compatibility, there only things for
> ATA.

What do you mean by ATAPI ioctl - TASK or TASKFILE ioctl or something else?

-- 
tejun

Re: Merging libata PATA support into the base kernel

[Jeff Garzik]

Matthieu CASTET wrote:
> On Fri, 11 Aug 2006 11:47:07 -0400, Mark Lord wrote:
>> And libata already has sufficient ioctl compatibility for nearly all
>> purposes with the old drivers/ide stuff.  Yes, there are some more
>> esoteric ioctls that I once implemented in drivers/ide that do not
>> exist for libata, and nobody will miss them.

> IRRC, there nothing for ATAPI ioctl compatibility, there only things for
> ATA.

What _specifically_ is missing, in your opinion?

	Jeff

/dev/sd*

[Adrian Bunk]

On Wed, Aug 09, 2006 at 06:29:59PM +0100, Alan Cox wrote:
>...
> - Drives appear as /dev/sda /dev/sr0 etc along with the libata SATA
> devices (and since you can't tell SATA from PATA at times its hard to
> avoid). That means people with some older distros wanting to try it
> might need to change their fstab or rootdev. People not trying it won't
> be affected.
>...

It might be a bit out of the scope of this thread, but why do some many 
subsystems use the /dev/sd* namespace?

Real SCSI devices use it.
The USB mass storage driver uses it.
libata uses it.

I'd expext SATA or PATA devices at /dev/hd* or perhaps at /dev/ata* - 
but why are they at /dev/sd*?

> Alan

cu
Adrian

-- 

    Gentoo kernels are 42 times more popular than SUSE kernels among
    KLive users  (a service by SUSE contractor Andrea Arcangeli that
    gathers data about kernels from many users worldwide).

       There are three kinds of lies: Lies, Damn Lies, and Statistics.
                                                    Benjamin Disraeli

Re: /dev/sd*

[Mark Lord]

Adrian Bunk wrote:
> 
> It might be a bit out of the scope of this thread, but why do some many 
> subsystems use the /dev/sd* namespace?

Because when those subsystems were first written, the only way one could install
most major distros was to use /dev/hd* or /dev/sd* as the device name.
This is still the case with many distros, though udev is helping get rid
of the hardcoding as time moves on.

So libata, USB, and firewire all were implemented as SCSI low-level drivers,
(rather than as independent block drivers), and thus inherited the /dev/sd* namespace.

They were not implemented as IDE low-level drivers, because the IDE subsystem
was never designed for hot-pluggable devices.

Cheers

Re: /dev/sd*

[Alan Cox]

Ar Mer, 2006-08-09 am 23:21 +0200, ysgrifennodd Adrian Bunk:
> It might be a bit out of the scope of this thread, but why do some many 
> subsystems use the /dev/sd* namespace?
> 
> Real SCSI devices use it.
> The USB mass storage driver uses it.

USB storage is real SCSI.

> libata uses it.
> 
> I'd expext SATA or PATA devices at /dev/hd* or perhaps at /dev/ata* - 
> but why are they at /dev/sd*?

ATA uses the top half of the scsi stack so ends up using the top layer
scsi drivers. Its probably more efficient than writing new driver
clones, especially as non disk ATA is also real SCSI (or very close).

You can use /dev/ata if you want - its just a udev problem ;)

Alan

Re: /dev/sd*

[Adrian Bunk]

On Wed, Aug 09, 2006 at 11:01:43PM +0100, Alan Cox wrote:
> Ar Mer, 2006-08-09 am 23:21 +0200, ysgrifennodd Adrian Bunk:
> > It might be a bit out of the scope of this thread, but why do some many 
> > subsystems use the /dev/sd* namespace?
> > 
> > Real SCSI devices use it.
> > The USB mass storage driver uses it.
> 
> USB storage is real SCSI.

Real SCSI for a developer, for a user it's USB.

And things become even more confusing considering that the drive might 
show up as /dev/sda or /dev/uba depending on the driver used.

> > libata uses it.
> > 
> > I'd expext SATA or PATA devices at /dev/hd* or perhaps at /dev/ata* - 
> > but why are they at /dev/sd*?
> 
> ATA uses the top half of the scsi stack so ends up using the top layer
> scsi drivers. Its probably more efficient than writing new driver
> clones, especially as non disk ATA is also real SCSI (or very close).

You are talking about kernel<->kernel and kernel<->hardware interfaces.

I'm more concerned about the kernel<->userspace interface.

> You can use /dev/ata if you want - its just a udev problem ;)

Or by adding some manual links if using a static /dev.

But I'm still not getting the point why the /dev/sd* namespace has to be 
used.

> Alan

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: /dev/sd*

[Alan Cox]

Ar Iau, 2006-08-10 am 00:18 +0200, ysgrifennodd Adrian Bunk:
> > USB storage is real SCSI.
> Real SCSI for a developer, for a user it's USB.

Define SCSI ?

> And things become even more confusing considering that the drive might 
> show up as /dev/sda or /dev/uba depending on the driver used.

Windows people seem to cope ok with C: being IDE and E: being SCSI ;)

> I'm more concerned about the kernel<->userspace interface.

Thats a naming policy matter, udev.

> But I'm still not getting the point why the /dev/sd* namespace has to be 
> used.

Because the block layer approach to major/minor numbers means everything
using sd (ie everything scsi disk protocol) gets the same device naming
scheme.

Alan

Re: /dev/sd*

[Jan Engelhardt]

>> And things become even more confusing considering that the drive might 
>> show up as /dev/sda or /dev/uba depending on the driver used.
>
>Windows people seem to cope ok with C: being IDE and E: being SCSI ;)

You can't compare it like that. Actually, drive letters are more like
bind mounts from "device names" to drive letters. In fact, net drives
are not IDE or SCSI or USB at all, yet they have a drive letter. So the
real CDROM for example is, IIRC, sth. like \\Device\Cdrom0 (it's not a
network path even if it looks like).


Jan Engelhardt
-- 

Re: /dev/sd*

[Greg KH]

On Thu, Aug 10, 2006 at 12:18:57AM +0200, Adrian Bunk wrote:
> On Wed, Aug 09, 2006 at 11:01:43PM +0100, Alan Cox wrote:
> > Ar Mer, 2006-08-09 am 23:21 +0200, ysgrifennodd Adrian Bunk:
> > > It might be a bit out of the scope of this thread, but why do some many 
> > > subsystems use the /dev/sd* namespace?
> > > 
> > > Real SCSI devices use it.
> > > The USB mass storage driver uses it.
> > 
> > USB storage is real SCSI.
> 
> Real SCSI for a developer, for a user it's USB.

So?  Users of Linux know to look for their USB storage devices in
/dev/sd* because of this.

> And things become even more confusing considering that the drive might 
> show up as /dev/sda or /dev/uba depending on the driver used.

And udev causes this to be moot, as people use the /dev/disk/by-*
symlinks, which are the same if they use the usb-storage or ub driver.

Same thing will happen for the changes that Alan is going to do (which I
think is the right thing to have happen.)

> > > libata uses it.
> > > 
> > > I'd expext SATA or PATA devices at /dev/hd* or perhaps at /dev/ata* - 
> > > but why are they at /dev/sd*?
> > 
> > ATA uses the top half of the scsi stack so ends up using the top layer
> > scsi drivers. Its probably more efficient than writing new driver
> > clones, especially as non disk ATA is also real SCSI (or very close).
> 
> You are talking about kernel<->kernel and kernel<->hardware interfaces.
> 
> I'm more concerned about the kernel<->userspace interface.
> 
> > You can use /dev/ata if you want - its just a udev problem ;)
> 
> Or by adding some manual links if using a static /dev.

Sure, but most distros don't have a static /dev anymore.

> But I'm still not getting the point why the /dev/sd* namespace has to be 
> used.

Because it has for USB storage devices since the 2.2 kernel.

Ok, 2.3, but then quickly backported to 2.2...  You want to break that
userspace interface?  :)

thanks,

greg k-h

Re: /dev/sd*

[Gabor Gombas]

On Thu, Aug 10, 2006 at 12:18:57AM +0200, Adrian Bunk wrote:

> Real SCSI for a developer, for a user it's USB.

For a user it's a "disk" no matter what cable type (SCSI, SATA, USB,
Firewire...) is used for connecting it to the computer. You can even
connect the very same disk to the machine using either SATA/PATA, USB or
Firewire cables depending on the enclosure, so making the naming of
SATA/PATA/USB/etc. disks different is much more confusing.

AFAIR long ago Linus said he'd like just one major number (and thus only
one naming scheme) for every disk in the system; with /dev/sd* we're now
getting there.

Gabor

-- 
     ---------------------------------------------------------
     MTA SZTAKI Computer and Automation Research Institute
                Hungarian Academy of Sciences
     ---------------------------------------------------------

Re: /dev/sd*

[Jeff Garzik]

Gabor Gombas wrote:
> AFAIR long ago Linus said he'd like just one major number (and thus only
> one naming scheme) for every disk in the system; with /dev/sd* we're now
> getting there.

Yep.  /dev/disk is a long term goal :)

	Jeff

Re: /dev/sd*

[Lee Trager]

Jeff Garzik wrote:
> Gabor Gombas wrote:
>> AFAIR long ago Linus said he'd like just one major number (and thus only
>> one naming scheme) for every disk in the system; with /dev/sd* we're now
>> getting there.
>
> Yep.  /dev/disk is a long term goal :)
>
>     Jeff
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
I agree with Adrian, users are going to get confused if their devices
are named something different once they switch to this new interface. So
if we're going to confusing them why not just take the big leap and
switch it over to /dev/disk? It seems to make more sense then to have
all IDE and SATA users use /dev/sda for awhile only to down the road
have to to switch to /dev/disk.

Re: /dev/sd*

[Michael Tokarev]

Lee Trager wrote:
> Jeff Garzik wrote:
>> Gabor Gombas wrote:
>>> AFAIR long ago Linus said he'd like just one major number (and thus only
>>> one naming scheme) for every disk in the system; with /dev/sd* we're now
>>> getting there.
>> Yep.  /dev/disk is a long term goal :)
[]
> I agree with Adrian, users are going to get confused if their devices
> are named something different once they switch to this new interface. So
> if we're going to confusing them why not just take the big leap and
> switch it over to /dev/disk? It seems to make more sense then to have
> all IDE and SATA users use /dev/sda for awhile only to down the road
> have to to switch to /dev/disk.

The reason, in my opinion anyway, is that not all the word is IDE now,
and it has been this way for a long time.  I mean, real scsi uses /dev/sd*
*right now*, and changing this to /dev/disk* will break just everything,
not only people using IDE.

/mjt

Re: /dev/sd*

[Jan Engelhardt]

>>>> AFAIR long ago Linus said he'd like just one major number (and thus only
>>>> one naming scheme) for every disk in the system; with /dev/sd* we're now
>>>> getting there.
>>> Yep.  /dev/disk is a long term goal :)
>[]
>> I agree with Adrian, users are going to get confused if their devices
>> are named something different once they switch to this new interface. So
>> if we're going to confusing them why not just take the big leap and
>> switch it over to /dev/disk? It seems to make more sense then to have
>> all IDE and SATA users use /dev/sda for awhile only to down the road
>> have to to switch to /dev/disk.
>
>The reason, in my opinion anyway, is that not all the word is IDE now,
>and it has been this way for a long time.  I mean, real scsi uses /dev/sd*
>*right now*, and changing this to /dev/disk* will break just everything,
>not only people using IDE.

Some people already went through this when devfs hit the scene, and once again
when it left the scene. Should be practiced now :)


Jan Engelhardt
-- 

Re: /dev/sd*

[Alan Cox]

Ar Iau, 2006-08-17 am 11:58 +0400, ysgrifennodd Michael Tokarev:
> The reason, in my opinion anyway, is that not all the word is IDE now,
> and it has been this way for a long time.  I mean, real scsi uses /dev/sd*
> *right now*, and changing this to /dev/disk* will break just everything,
> not only people using IDE.

If people would like their disks to appear in /dev/disk/ by label or
whatever just send Greg some udev rules for it. It isnt a kernel problem
what it is called just some of the things around partitions

Re: /dev/sd*

[Jan Engelhardt]

>>> AFAIR long ago Linus said he'd like just one major number (and thus only
>>> one naming scheme) for every disk in the system; with /dev/sd* we're now
>>> getting there.
>>
>> Yep.  /dev/disk is a long term goal :)
>>
>I agree with Adrian, users are going to get confused if their devices
>are named something different once they switch to this new interface. So
>if we're going to confusing them why not just take the big leap and
>switch it over to /dev/disk? It seems to make more sense then to have
>all IDE and SATA users use /dev/sda for awhile only to down the road
>have to to switch to /dev/disk.

In the process, we can rename the then-"generic disk" (scsi ide whatever) 
back to "hd*" since that actually expands to Hard Disk.
(If I would have known a lot earlier about Linux I would have proposed 
"id*" for the IDE disks.)


Jan Engelhardt
-- 

Re: /dev/sd*

[Lee Trager]

Jan Engelhardt wrote:
>>>> AFAIR long ago Linus said he'd like just one major number (and thus only
>>>> one naming scheme) for every disk in the system; with /dev/sd* we're now
>>>> getting there.
>>>>         
>>> Yep.  /dev/disk is a long term goal :)
>>>
>>>       
>> I agree with Adrian, users are going to get confused if their devices
>> are named something different once they switch to this new interface. So
>> if we're going to confusing them why not just take the big leap and
>> switch it over to /dev/disk? It seems to make more sense then to have
>> all IDE and SATA users use /dev/sda for awhile only to down the road
>> have to to switch to /dev/disk.
>>     
>
> In the process, we can rename the then-"generic disk" (scsi ide whatever) 
> back to "hd*" since that actually expands to Hard Disk.
> (If I would have known a lot earlier about Linux I would have proposed 
> "id*" for the IDE disks.)
>
>
> Jan Engelhardt
>   
Actually that does make more sense then using disk. So I guess we're
back to square one. Personally I don't think its that big of a deal, all
you have to do is change fstab and grub or lilo. My main concern is for
the less advanced Linux users.

Re: /dev/sd*

[Jan Engelhardt]

>> In the process, we can rename the then-"generic disk" (scsi ide whatever) 
>> back to "hd*" since that actually expands to Hard Disk.
>> (If I would have known a lot earlier about Linux I would have proposed 
>> "id*" for the IDE disks.)
>>
>Actually that does make more sense then using disk. So I guess we're
>back to square one. Personally I don't think its that big of a deal, all
>you have to do is change fstab and grub or lilo. My main concern is for
>the less advanced Linux users.

Less advanced users should use the upgrade tools their distribution 
provides.


Jan Engelhardt
-- 

Re: /dev/sd*

[Seewer Philippe]

Jan Engelhardt wrote:
>>> In the process, we can rename the then-"generic disk" (scsi ide whatever) 
>>> back to "hd*" since that actually expands to Hard Disk.
>>> (If I would have known a lot earlier about Linux I would have proposed 
>>> "id*" for the IDE disks.)
>>>
>> Actually that does make more sense then using disk. So I guess we're
>> back to square one. Personally I don't think its that big of a deal, all
>> you have to do is change fstab and grub or lilo. My main concern is for
>> the less advanced Linux users.
> 
> Less advanced users should use the upgrade tools their distribution 
> provides.

And personally I think less advanced users will be very happy with
/dev/disk (or /dev/hd). No more confusion wether to user /dev/hdx or
/dev/sdx or whatever!

Philippe Seewer

Re: /dev/sd*

[Jan Engelhardt]

>> Less advanced users should use the upgrade tools their distribution 
>> provides.
>
>And personally I think less advanced users will be very happy with
>/dev/disk (or /dev/hd). No more confusion wether to user /dev/hdx or
>/dev/sdx or whatever!

Umm, hdx or sdx is a small impact. The real power of /dev/disk is that 
not-so-technically minded users can go looking for their disk by its name 
(or less frequently, by their address (e.g. USB drive)). Especially 
important since any new disk discovered in the scsi layer gets the next 
free slot.


Jan Engelhardt
-- 

Re: /dev/sd*

[Tejun Heo]

Jan Engelhardt wrote:
>>> Less advanced users should use the upgrade tools their distribution 
>>> provides.
>> And personally I think less advanced users will be very happy with
>> /dev/disk (or /dev/hd). No more confusion wether to user /dev/hdx or
>> /dev/sdx or whatever!
> 
> Umm, hdx or sdx is a small impact. The real power of /dev/disk is that 
> not-so-technically minded users can go looking for their disk by its name 
> (or less frequently, by their address (e.g. USB drive)). Especially 
> important since any new disk discovered in the scsi layer gets the next 
> free slot.

Desktop volume management stuff is already doing it.  When I connect my 
ipod, it shows up as IPOD on my desktop regardless of which sd letter it 
gets.  Also, recent distributions use LABEL= tricks to find out root and 
other partitions to mount on boot.

The major/minor number and device name (which is determined by udev) 
aren't that important already and will become less of an issue as time 
passes.

-- 
tejun

Re: /dev/sd*

[Alan Cox]

Ar Gwe, 2006-08-18 am 10:52 +0200, ysgrifennodd Jan Engelhardt:
> Umm, hdx or sdx is a small impact. The real power of /dev/disk is that 
> not-so-technically minded users can go looking for their disk by its name 

They already can. It appears on their desktop with a little picture that
says "My iSpod" or similar 8)

What sort of "name" are you considering for /dev/disk ?

Alan

Re: /dev/sd*

[Jan Engelhardt]

>> Umm, hdx or sdx is a small impact. The real power of /dev/disk is that 
>> not-so-technically minded users can go looking for their disk by its name 
>
>They already can. It appears on their desktop with a little picture that
>says "My iSpod" or similar 8)

Not everyone follows Linus's "suggestion" to use KDE. Actually, there are 
even people not thrilled by either KDE or GNOME.

>What sort of "name" are you considering for /dev/disk ?

Whatever udev does currently seems good:

17:48 shanghai:~ > ls /dev/disk/by-id/*
/dev/disk/by-id/ata-DIAMOND_250G_2B5400_030400026
/dev/disk/by-id/ata-DIAMOND_250G_2B5400_030400026-part1
/dev/disk/by-id/usb-0_USB_DRIVE_0000000000004287
/dev/disk/by-id/usb-0_USB_DRIVE_0000000000004287-part1



Jan Engelhardt
-- 

Re: /dev/sd*

[Lee Revell]

On Fri, 2006-08-18 at 17:51 +0200, Jan Engelhardt wrote:
> >> Umm, hdx or sdx is a small impact. The real power of /dev/disk is that 
> >> not-so-technically minded users can go looking for their disk by its name 
> >
> >They already can. It appears on their desktop with a little picture that
> >says "My iSpod" or similar 8)
> 
> Not everyone follows Linus's "suggestion" to use KDE. Actually, there are 
> even people not thrilled by either KDE or GNOME.

It works the same way in Gnome (and any reasonable desktop OS).  If
users really don't want an integrated desktop environment I think they
get to figure out the disk naming issues themselves.

Lee

Re: /dev/sd*

[Alan Cox]

Ar Gwe, 2006-08-18 am 17:51 +0200, ysgrifennodd Jan Engelhardt:
> Whatever udev does currently seems good:
> 
> 17:48 shanghai:~ > ls /dev/disk/by-id/*
> /dev/disk/by-id/ata-DIAMOND_250G_2B5400_030400026
> /dev/disk/by-id/ata-DIAMOND_250G_2B5400_030400026-part1
> /dev/disk/by-id/usb-0_USB_DRIVE_0000000000004287
> /dev/disk/by-id/usb-0_USB_DRIVE_0000000000004287-part1

I wouldn't try that on a typical "non technical user", at least except
for Halloween 8)

Re: /dev/sd*

[Lee Trager]

Alan Cox wrote:
> Ar Gwe, 2006-08-18 am 17:51 +0200, ysgrifennodd Jan Engelhardt:
>   
>> Whatever udev does currently seems good:
>>
>> 17:48 shanghai:~ > ls /dev/disk/by-id/*
>> /dev/disk/by-id/ata-DIAMOND_250G_2B5400_030400026
>> /dev/disk/by-id/ata-DIAMOND_250G_2B5400_030400026-part1
>> /dev/disk/by-id/usb-0_USB_DRIVE_0000000000004287
>> /dev/disk/by-id/usb-0_USB_DRIVE_0000000000004287-part1
>>     
>
> I wouldn't try that on a typical "non technical user", at least except
> for Halloween 8)
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>   
Why not make libata use /dev/disk by default and have a kernel option
for legacy naming(ide disks are hda, sata are sda etc)?

Re: /dev/sd*

[Jan Engelhardt]

>>> Whatever udev does currently seems good:
>>>
>>> 17:48 shanghai:~ > ls /dev/disk/by-id/*
>>> /dev/disk/by-id/ata-DIAMOND_250G_2B5400_030400026
>>> /dev/disk/by-id/ata-DIAMOND_250G_2B5400_030400026-part1
>>> /dev/disk/by-id/usb-0_USB_DRIVE_0000000000004287
>>> /dev/disk/by-id/usb-0_USB_DRIVE_0000000000004287-part1
>>
>> I wouldn't try that on a typical "non technical user", at least except
>> for Halloween 8)
>>
>Why not make libata use /dev/disk by default and have a kernel option
>for legacy naming(ide disks are hda, sata are sda etc)?

The kernel does not really know about device names.
It is all udev that manages it. Or the user, in case he can manage to get fixed
device numbers.


Jan Engelhardt
-- 

Re: /dev/sd*

[Bill Davidsen]

Seewer Philippe wrote:
> Jan Engelhardt wrote:
>>>> In the process, we can rename the then-"generic disk" (scsi ide whatever) 
>>>> back to "hd*" since that actually expands to Hard Disk.
>>>> (If I would have known a lot earlier about Linux I would have proposed 
>>>> "id*" for the IDE disks.)
>>>>
>>> Actually that does make more sense then using disk. So I guess we're
>>> back to square one. Personally I don't think its that big of a deal, all
>>> you have to do is change fstab and grub or lilo. My main concern is for
>>> the less advanced Linux users.
>> Less advanced users should use the upgrade tools their distribution 
>> provides.
> 
> And personally I think less advanced users will be very happy with
> /dev/disk (or /dev/hd). No more confusion wether to user /dev/hdx or
> /dev/sdx or whatever!
> 
But less clarity about which name goes with which device. I think it's 
desirable to have a way for the user, the non-guru user, to find out 
what meaningless name goes with which actual device. Currently finding 
out what's on a system involves /proc/ide/hd*/model and /proc/scsi/scsi 
to see what's attached and what names are being used.

For discussion I suggest /proc/ata/devices, a single flat file matching 
a name meaningful to open() with a vendor string and whatever other info 
is handy, like serial number and the like. If people are going to use 
ATA that allows them to generate their own tools using familiar methods 
like awk, sed, grep, perl, python or whatever. Having that information 
in an inobvious format will really slow adoption by triggering the "it's 
hard to use" or "I need to use all these new tools" responses.

And those responses are not limited to newbies, experienced users are 
aware of the ratio of learning curve to functionality as well.

-- 
Bill Davidsen <davidsen@tmr.com>
   Obscure bug of 2004: BASH BUFFER OVERFLOW - if bash is being run by a
normal user and is setuid root, with the "vi" line edit mode selected,
and the character set is "big5," an off-by-one errors occurs during
wildcard (glob) expansion.

Re: /dev/sd*

[Jan Engelhardt]

>
> For discussion I suggest /proc/ata/devices, a single flat file

Ahem. /sys please. And do not just limit it to ATA.

> matching a name meaningful to open() with a vendor string and
> whatever other info is handy, like serial number and the like. If
> people are going to use ATA that allows them to generate their own
> tools using familiar methods like awk, sed, grep, perl, python or
> whatever. Having that information in an inobvious format will really
> slow adoption by triggering the "it's hard to use" or "I need to use
> all these new tools" responses.
>
> And those responses are not limited to newbies, experienced users are aware of
> the ratio of learning curve to functionality as well.

What would the contents of /ata/devices look like, can you give an
example?


Jan Engelhardt
-- 

Re: /dev/sd*

[Gabor Gombas]

On Fri, Aug 18, 2006 at 08:45:38AM -0400, Bill Davidsen wrote:

> For discussion I suggest /proc/ata/devices, a single flat file matching 
> a name meaningful to open() with a vendor string and whatever other info 
> is handy, like serial number and the like.

Why just ATA? Let it contain all disk-like devices in the system, and
add an extra field showing the transport method
(IDE/USB/SCSI/SATA/whatever) the device is currently using.

Hmm, /sys/block already contains all the kernel-internal device names,
/sys/block/*/device already gives the physical location. We might just
need a couple additional attributes (like "serial") for user
convenience, and a little shell script that walks /sys/block and emits
an unified device list?

Alternatively, the shell scipt could use blktool to collect the data not
already present under /sys/block, so there would be no need to modify
the kernel at all. blktool could be modified to accept a path name under
/sys/block as well as a device node, and print some more data the serial
number when using the "id" command, but I think that's doable.

Gabor

-- 
     ---------------------------------------------------------
     MTA SZTAKI Computer and Automation Research Institute
                Hungarian Academy of Sciences
     ---------------------------------------------------------

Re: /dev/sd*

[Alan Cox]

Ar Iau, 2006-08-17 am 10:01 +0200, ysgrifennodd Jan Engelhardt:
> (If I would have known a lot earlier about Linux I would have proposed 
> "id*" for the IDE disks.)

IDE basically did not exist at the time that the hd name was chosen. 

Re: Merging libata PATA support into the base kernel

[Andi Kleen]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> - No support for host-protected-area yet

Even the support in the old one for that wasn't complete. It didn't
redo the HPA disabling on resume-from-ram, which made parts of the
disk not accessible anymore after wakeup. So at least on laptops it
always had to be disabled anyways.

-Andi

Re: Merging libata PATA support into the base kernel

[Alan Cox]

Ar Iau, 2006-08-10 am 08:24 +0200, ysgrifennodd Andi Kleen:
> Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> > - No support for host-protected-area yet
> 
> Even the support in the old one for that wasn't complete. It didn't
> redo the HPA disabling on resume-from-ram, which made parts of the
> disk not accessible anymore after wakeup. So at least on laptops it
> always had to be disabled anyways.

drivers/ide does not support power management yet. Never has. Some
people are brave and use it as it is rather than fix it.

Alan

Re: Merging libata PATA support into the base kernel

[Jens Axboe]

On Thu, Aug 10 2006, Alan Cox wrote:
> Ar Iau, 2006-08-10 am 08:24 +0200, ysgrifennodd Andi Kleen:
> > Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> > > - No support for host-protected-area yet
> > 
> > Even the support in the old one for that wasn't complete. It didn't
> > redo the HPA disabling on resume-from-ram, which made parts of the
> > disk not accessible anymore after wakeup. So at least on laptops it
> > always had to be disabled anyways.
> 
> drivers/ide does not support power management yet. Never has. Some
> people are brave and use it as it is rather than fix it.

You make it sound much worse than it is. Apart for HPA, I'm not aware of
any setups that require extra treatment. And the amount of reported bugs
against it are pretty close to zero :-)

-- 
Jens Axboe

Re: Merging libata PATA support into the base kernel

[Alan Cox]

Ar Iau, 2006-08-10 am 14:20 +0200, ysgrifennodd Jens Axboe:
> You make it sound much worse than it is. Apart for HPA, I'm not aware of
> any setups that require extra treatment. And the amount of reported bugs
> against it are pretty close to zero :-)

There are several variants where you get
	- hangs on resume
	- HPA mishandling
	- CRC errors and usually eventually a hang

HPA thankfully appears to bite only IBM thinkpad users

Re: Merging libata PATA support into the base kernel

[Jens Axboe]

On Thu, Aug 10 2006, Alan Cox wrote:
> Ar Iau, 2006-08-10 am 14:20 +0200, ysgrifennodd Jens Axboe:
> > You make it sound much worse than it is. Apart for HPA, I'm not aware of
> > any setups that require extra treatment. And the amount of reported bugs
> > against it are pretty close to zero :-)
> 
> There are several variants where you get

Not very vocal users then, or I missed them.

> 	- hangs on resume
> 	- HPA mishandling
> 	- CRC errors and usually eventually a hang

HPA mishandling is a given, I agree that is a nasty problem and really
should be fixed. hangs on resume - the hardware, or the kernel talking
to it? crc errors sounds like bad transfer tuning after resume, but that
should be pretty identical to the on-boot one.

The low level drivers/ide drivers aren't well geared for suspend/resume,
perhaps that is what is causing most of these issues (apart from hpa).

-- 
Jens Axboe

Re: Merging libata PATA support into the base kernel

[Alan Cox]

Ar Iau, 2006-08-10 am 15:59 +0200, ysgrifennodd Jens Axboe:
> On Thu, Aug 10 2006, Alan Cox wrote:
> HPA mishandling is a given, I agree that is a nasty problem and really
> should be fixed. hangs on resume - the hardware, or the kernel talking

Hang on resume because we don't do the mode setup right from s2ram.
Being worked on by someone at last which is great

> to it? crc errors sounds like bad transfer tuning after resume, but that
> should be pretty identical to the on-boot one.

I *think* this is that the PLLs need resynchronizing after resume from
ram and we don't do that for some chips

Re: Merging libata PATA support into the base kernel

[Jason Lunz]

In gmane.linux.kernel, you wrote:
> You make it sound much worse than it is. Apart for HPA, I'm not aware of
> any setups that require extra treatment. And the amount of reported bugs
> against it are pretty close to zero :-)

*ahem*.

I needed to do this to cure IDE hangs on resume:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc3/2.6.18-rc3-mm2/broken-out/ide-reprogram-disk-pio-timings-on-resume.patch

Are you watching the suspend mailing lists? There's no shortage of them:

suspend-devel:	http://dir.gmane.org/gmane.linux.kernel.suspend.devel
linux-pm:	http://dir.gmane.org/gmane.linux.power-management.general
suspend2-devel:	http://dir.gmane.org/gmane.linux.swsusp.devel
suspend2-users:	http://dir.gmane.org/gmane.linux.swsusp.general

I'm currently trying to help out one Sheer El-Showk, whose piix ide
requires 30 seconds of floundering followed by a bus reset to resume:

http://thread.gmane.org/gmane.linux.kernel.suspend.devel/276/focus=347

But I know next-to-nothing about ATA.

It's not surprising you're not getting many bug reports. It's common for
several things to go wrong during s2ram, and the user often ends up
looking at a hung system with a dead screen. It takes some quality time
with netconsole to even begin to narrow down that it's IDE hanging the
system, after which you can *begin* solving the no-video-on-resume
issue.

Jason

Re: Merging libata PATA support into the base kernel

[Rafael J. Wysocki]

On Thursday 10 August 2006 21:02, Jason Lunz wrote:
> In gmane.linux.kernel, you wrote:
> > You make it sound much worse than it is. Apart for HPA, I'm not aware of
> > any setups that require extra treatment. And the amount of reported bugs
> > against it are pretty close to zero :-)

No, it's not.

> *ahem*.
> 
> I needed to do this to cure IDE hangs on resume:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc3/2.6.18-rc3-mm2/broken-out/ide-reprogram-disk-pio-timings-on-resume.patch
> 
> Are you watching the suspend mailing lists? There's no shortage of them:
> 
> suspend-devel:	http://dir.gmane.org/gmane.linux.kernel.suspend.devel
> linux-pm:	http://dir.gmane.org/gmane.linux.power-management.general
> suspend2-devel:	http://dir.gmane.org/gmane.linux.swsusp.devel
> suspend2-users:	http://dir.gmane.org/gmane.linux.swsusp.general
> 
> I'm currently trying to help out one Sheer El-Showk, whose piix ide
> requires 30 seconds of floundering followed by a bus reset to resume:
> 
> http://thread.gmane.org/gmane.linux.kernel.suspend.devel/276/focus=347
> 
> But I know next-to-nothing about ATA.
> 
> It's not surprising you're not getting many bug reports. It's common for
> several things to go wrong during s2ram, and the user often ends up
> looking at a hung system with a dead screen. It takes some quality time
> with netconsole to even begin to narrow down that it's IDE hanging the
> system, after which you can *begin* solving the no-video-on-resume
> issue.

I agree.  Moreover, the disk-related resume-from-ram problems are the hardest
ones (the graphics may be handled from the user land to a reasonable extent).

Actually, I'm looking for someone who'd agree to be Cced on bug reports where
we suspect the problem may be related to IDE/PATA/SATA . ;-)

Greetings,
Rafael

Re: Merging libata PATA support into the base kernel

[Lee Trager]

Rafael J. Wysocki wrote:
> On Thursday 10 August 2006 21:02, Jason Lunz wrote:
>   
>> In gmane.linux.kernel, you wrote:
>>     
>>> You make it sound much worse than it is. Apart for HPA, I'm not aware of
>>> any setups that require extra treatment. And the amount of reported bugs
>>> against it are pretty close to zero :-)
>>>       
>
> No, it's not.
>
>   
>> *ahem*.
>>
>> I needed to do this to cure IDE hangs on resume:
>>
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc3/2.6.18-rc3-mm2/broken-out/ide-reprogram-disk-pio-timings-on-resume.patch
>>
>> Are you watching the suspend mailing lists? There's no shortage of them:
>>
>> suspend-devel:	http://dir.gmane.org/gmane.linux.kernel.suspend.devel
>> linux-pm:	http://dir.gmane.org/gmane.linux.power-management.general
>> suspend2-devel:	http://dir.gmane.org/gmane.linux.swsusp.devel
>> suspend2-users:	http://dir.gmane.org/gmane.linux.swsusp.general
>>
>> I'm currently trying to help out one Sheer El-Showk, whose piix ide
>> requires 30 seconds of floundering followed by a bus reset to resume:
>>
>> http://thread.gmane.org/gmane.linux.kernel.suspend.devel/276/focus=347
>>
>> But I know next-to-nothing about ATA.
>>
>> It's not surprising you're not getting many bug reports. It's common for
>> several things to go wrong during s2ram, and the user often ends up
>> looking at a hung system with a dead screen. It takes some quality time
>> with netconsole to even begin to narrow down that it's IDE hanging the
>> system, after which you can *begin* solving the no-video-on-resume
>> issue.
>>     
>
> I agree.  Moreover, the disk-related resume-from-ram problems are the hardest
> ones (the graphics may be handled from the user land to a reasonable extent).
>
> Actually, I'm looking for someone who'd agree to be Cced on bug reports where
> we suspect the problem may be related to IDE/PATA/SATA . ;-)
>
> Greetings,
> Rafael
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>   
Well it seems I am one of those users who is bit by the resume bug. I
was wondering why no developer has replied to my
bug(http://bugzilla.kernel.org/show_bug.cgi?id=6840) even though many
users have. Id try to fix it myself but Ive never done kernel hacking. I
haven't posted on the linux suspend lists because I talked to one of the
suspend2 developers who told me that the problem was with the ide driver
and thus could not help me.

Re: Merging libata PATA support into the base kernel

[Pavel Machek]

> > I agree.  Moreover, the disk-related resume-from-ram problems are the hardest
> > ones (the graphics may be handled from the user land to a reasonable extent).
> >
> > Actually, I'm looking for someone who'd agree to be Cced on bug reports where
> > we suspect the problem may be related to IDE/PATA/SATA . ;-)
> >
> > Greetings,
> > Rafael
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> >   
> Well it seems I am one of those users who is bit by the resume bug. I
> was wondering why no developer has replied to my
> bug(http://bugzilla.kernel.org/show_bug.cgi?id=6840) even though many
> users have. Id try to fix it myself but Ive never done kernel

Time to learn?

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Merging libata PATA support into the base kernel

[Alan Cox]

Ar Iau, 2006-08-17 am 11:18 +0200, ysgrifennodd Pavel Machek:
> > Well it seems I am one of those users who is bit by the resume bug. I
> > was wondering why no developer has replied to my
> > bug(http://bugzilla.kernel.org/show_bug.cgi?id=6840) even though many
> > users have. Id try to fix it myself but Ive never done kernel

Probably because its a repeat of a well known problem and nobody has
volunteered to fix it even when its been explained to them

When we set the HPA on boot we must do the same on resume or the error
you see occurs.

> 
> Time to learn?
> 
> 								Pavel

Re: Merging libata PATA support into the base kernel

[Pavel Machek]

Hi!

> > > Well it seems I am one of those users who is bit by the resume bug. I
> > > was wondering why no developer has replied to my
> > > bug(http://bugzilla.kernel.org/show_bug.cgi?id=6840) even though many
> > > users have. Id try to fix it myself but Ive never done kernel
> 
> Probably because its a repeat of a well known problem and nobody has
> volunteered to fix it even when its been explained to them
> 
> When we set the HPA on boot we must do the same on resume or the error
> you see occurs.

This should not be it... it also happens on suspend-to-disk according
to the report, and during swsusp we do normal boot so HPA should be
initialized...?
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Merging libata PATA support into the base kernel

[Alan Cox]

Ar Iau, 2006-08-17 am 11:45 +0200, ysgrifennodd Pavel Machek:
> This should not be it... it also happens on suspend-to-disk according
> to the report, and during swsusp we do normal boot so HPA should be
> initialized...?

The suspend to disk case I've not personally seen. The suspend to ram
one I have looked at and seen and verified the HPA was not reset.

Re: Merging libata PATA support into the base kernel

[Lee Trager]

Alan Cox wrote:
> Ar Iau, 2006-08-17 am 11:45 +0200, ysgrifennodd Pavel Machek:
>   
>> This should not be it... it also happens on suspend-to-disk according
>> to the report, and during swsusp we do normal boot so HPA should be
>> initialized...?
>>     
>
> The suspend to disk case I've not personally seen. The suspend to ram
> one I have looked at and seen and verified the HPA was not reset.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>   
Well how do we reset HPA? If someone could point me in the right
direction I could try to get it to work, although I've never really done
any kernel hacking before. Im not even sure what HPA is, Wikipedia has
nothing on it so I guess I'll google around.

Re: Merging libata PATA support into the base kernel

[Lee Trager]

Lee Trager wrote:
> Alan Cox wrote:
>   
>> Ar Iau, 2006-08-17 am 11:45 +0200, ysgrifennodd Pavel Machek:
>>   
>>     
>>> This should not be it... it also happens on suspend-to-disk according
>>> to the report, and during swsusp we do normal boot so HPA should be
>>> initialized...?
>>>     
>>>       
>> The suspend to disk case I've not personally seen. The suspend to ram
>> one I have looked at and seen and verified the HPA was not reset.
>>
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>   
>>     
> Well how do we reset HPA? If someone could point me in the right
> direction I could try to get it to work, although I've never really done
> any kernel hacking before. Im not even sure what HPA is, Wikipedia has
> nothing on it so I guess I'll google around.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>   
Ok I got it now. Anyway I tried disabling it in the BIOS(IBM called it
the Predesktop Area) and I still get the same thing.

Re: Merging libata PATA support into the base kernel

[Alan Cox]

Ar Iau, 2006-08-17 am 23:57 -0400, ysgrifennodd Lee Trager:
> Ok I got it now. Anyway I tried disabling it in the BIOS(IBM called it
> the Predesktop Area) and I still get the same thing.

You would. You'd need to reinstall not using the HPA area of the disk in
order to fix this, or patch the kernel to restore the HPA on resume

Re: Merging libata PATA support into the base kernel

[Lee Trager]

Alan Cox wrote:
> Ar Iau, 2006-08-17 am 23:57 -0400, ysgrifennodd Lee Trager:
>   
>> Ok I got it now. Anyway I tried disabling it in the BIOS(IBM called it
>> the Predesktop Area) and I still get the same thing.
>>     
>
> You would. You'd need to reinstall not using the HPA area of the disk in
> order to fix this, or patch the kernel to restore the HPA on resume
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>   
Well where in the kernel is the code that disabled HPA on startup? Im
new to kernel hacking so if you could point me in the right direction I
could try to patch it myself.

Re: Merging libata PATA support into the base kernel

[Alan Cox]

Ar Gwe, 2006-08-18 am 15:22 -0400, ysgrifennodd Lee Trager:
> Well where in the kernel is the code that disabled HPA on startup? Im
> new to kernel hacking so if you could point me in the right direction I
> could try to patch it myself.

drivers/ide/ide-disk.c

Particularly:
	idedisk_check_hpa()

which if you call at the end of the resume sequence for disks ought to
do the right thing for you

Re: Merging libata PATA support into the base kernel

[Lee Trager]

Alan Cox wrote:
> Ar Gwe, 2006-08-18 am 15:22 -0400, ysgrifennodd Lee Trager:
>   
>> Well where in the kernel is the code that disabled HPA on startup? Im
>> new to kernel hacking so if you could point me in the right direction I
>> could try to patch it myself.
>>     
>
> drivers/ide/ide-disk.c
>
> Particularly:
> 	idedisk_check_hpa()
>
> which if you call at the end of the resume sequence for disks ought to
> do the right thing for you
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>   
Well I tried to do exactly what you said. All that happens now is that
it does not come out of resume. Below is a patch of the code I tried to
do in case you could like to look at it. Basically I called
idedisk_check_hpa at the end of generic_ide_resume() in drivers/ide/ide.c

diff -Naur linux-2.6.18-rc4-old/drivers/ide/ide-disk.c
linux-2.6.18-rc4/drivers/ide/ide-disk.c
--- linux-2.6.18-rc4-old/drivers/ide/ide-disk.c    2006-08-19
03:49:03.000000000 -0400
+++ linux-2.6.18-rc4/drivers/ide/ide-disk.c    2006-08-19
03:41:33.000000000 -0400
@@ -464,16 +464,6 @@
 }
 
 /*
- * Bits 10 of command_set_1 and cfs_enable_1 must be equal,
- * so on non-buggy drives we need test only one.
- * However, we should also check whether these fields are valid.
- */
-static inline int idedisk_supports_hpa(const struct hd_driveid *id)
-{
-    return (id->command_set_1 & 0x0400) && (id->cfs_enable_1 & 0x0400);
-}
-
-/*
  * The same here.
  */
 static inline int idedisk_supports_lba48(const struct hd_driveid *id)
@@ -482,7 +472,7 @@
            && id->lba_capacity_2;
 }
 
-static void idedisk_check_hpa(ide_drive_t *drive)
+void idedisk_check_hpa(ide_drive_t *drive)
 {
     unsigned long long capacity, set_max;
     int lba48 = idedisk_supports_lba48(drive->id);
@@ -514,6 +504,8 @@
     }
 }
 
+EXPORT_SYMBOL(idedisk_check_hpa);
+
 /*
  * Compute drive->capacity, the full capacity of the drive
  * Called with drive->id != NULL.
diff -Naur linux-2.6.18-rc4-old/drivers/ide/ide.c
linux-2.6.18-rc4/drivers/ide/ide.c
--- linux-2.6.18-rc4-old/drivers/ide/ide.c    2006-08-19
03:49:03.000000000 -0400
+++ linux-2.6.18-rc4/drivers/ide/ide.c    2006-08-19 03:41:33.000000000
-0400
@@ -1242,6 +1242,13 @@
     rqpm.pm_step = ide_pm_state_start_resume;
     rqpm.pm_state = PM_EVENT_ON;
 
+    /* check to see if this is a hard drive
+     * if it is then checkhpa needs to be
+     * disabled */
+    if(drive->media == ide_disk)
+        if(idedisk_supports_hpa(drive->id))
+            idedisk_check_hpa(drive);
+
     return ide_do_drive_cmd(drive, &rq, ide_head_wait);
 }
diff -Naur linux-2.6.18-rc4-old/include/linux/ide.h
linux-2.6.18-rc4/include/linux/ide.h
--- linux-2.6.18-rc4-old/include/linux/ide.h    2006-08-19
03:49:03.000000000 -0400
+++ linux-2.6.18-rc4/include/linux/ide.h    2006-08-19
03:42:53.000000000 -0400
@@ -1377,4 +1377,16 @@
     return dev ? pcibus_to_node(dev->bus) : -1;
 }
 
+extern void idedisk_check_hpa(ide_drive_t *drive);
+
+/*
+ *  * Bits 10 of command_set_1 and cfs_enable_1 must be equal,
+ *   * so on non-buggy drives we need test only one.
+ *    * However, we should also check whether these fields are valid.
+ *     */
+static inline int idedisk_supports_hpa(const struct hd_driveid *id)
+{
+        return (id->command_set_1 & 0x0400) && (id->cfs_enable_1 & 0x0400);
+}
+
 #endif /* _IDE_H */

Re: Merging libata PATA support into the base kernel

[Lee Trager]

Lee Trager wrote:
> Alan Cox wrote:
>   
>> Ar Gwe, 2006-08-18 am 15:22 -0400, ysgrifennodd Lee Trager:
>>   
>>     
>>> Well where in the kernel is the code that disabled HPA on startup? Im
>>> new to kernel hacking so if you could point me in the right direction I
>>> could try to patch it myself.
>>>     
>>>       
>> drivers/ide/ide-disk.c
>>
>> Particularly:
>> 	idedisk_check_hpa()
>>
>> which if you call at the end of the resume sequence for disks ought to
>> do the right thing for you
>>
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>   
>>     
> Well I tried to do exactly what you said. All that happens now is that
> it does not come out of resume. Below is a patch of the code I tried to
> do in case you could like to look at it. Basically I called
> idedisk_check_hpa at the end of generic_ide_resume() in drivers/ide/ide.c
>
> diff -Naur linux-2.6.18-rc4-old/drivers/ide/ide-disk.c
> linux-2.6.18-rc4/drivers/ide/ide-disk.c
> --- linux-2.6.18-rc4-old/drivers/ide/ide-disk.c    2006-08-19
> 03:49:03.000000000 -0400
> +++ linux-2.6.18-rc4/drivers/ide/ide-disk.c    2006-08-19
> 03:41:33.000000000 -0400
> @@ -464,16 +464,6 @@
>  }
>  
>  /*
> - * Bits 10 of command_set_1 and cfs_enable_1 must be equal,
> - * so on non-buggy drives we need test only one.
> - * However, we should also check whether these fields are valid.
> - */
> -static inline int idedisk_supports_hpa(const struct hd_driveid *id)
> -{
> -    return (id->command_set_1 & 0x0400) && (id->cfs_enable_1 & 0x0400);
> -}
> -
> -/*
>   * The same here.
>   */
>  static inline int idedisk_supports_lba48(const struct hd_driveid *id)
> @@ -482,7 +472,7 @@
>             && id->lba_capacity_2;
>  }
>  
> -static void idedisk_check_hpa(ide_drive_t *drive)
> +void idedisk_check_hpa(ide_drive_t *drive)
>  {
>      unsigned long long capacity, set_max;
>      int lba48 = idedisk_supports_lba48(drive->id);
> @@ -514,6 +504,8 @@
>      }
>  }
>  
> +EXPORT_SYMBOL(idedisk_check_hpa);
> +
>  /*
>   * Compute drive->capacity, the full capacity of the drive
>   * Called with drive->id != NULL.
> diff -Naur linux-2.6.18-rc4-old/drivers/ide/ide.c
> linux-2.6.18-rc4/drivers/ide/ide.c
> --- linux-2.6.18-rc4-old/drivers/ide/ide.c    2006-08-19
> 03:49:03.000000000 -0400
> +++ linux-2.6.18-rc4/drivers/ide/ide.c    2006-08-19 03:41:33.000000000
> -0400
> @@ -1242,6 +1242,13 @@
>      rqpm.pm_step = ide_pm_state_start_resume;
>      rqpm.pm_state = PM_EVENT_ON;
>  
> +    /* check to see if this is a hard drive
> +     * if it is then checkhpa needs to be
> +     * disabled */
> +    if(drive->media == ide_disk)
> +        if(idedisk_supports_hpa(drive->id))
> +            idedisk_check_hpa(drive);
> +
>      return ide_do_drive_cmd(drive, &rq, ide_head_wait);
>  }
> diff -Naur linux-2.6.18-rc4-old/include/linux/ide.h
> linux-2.6.18-rc4/include/linux/ide.h
> --- linux-2.6.18-rc4-old/include/linux/ide.h    2006-08-19
> 03:49:03.000000000 -0400
> +++ linux-2.6.18-rc4/include/linux/ide.h    2006-08-19
> 03:42:53.000000000 -0400
> @@ -1377,4 +1377,16 @@
>      return dev ? pcibus_to_node(dev->bus) : -1;
>  }
>  
> +extern void idedisk_check_hpa(ide_drive_t *drive);
> +
> +/*
> + *  * Bits 10 of command_set_1 and cfs_enable_1 must be equal,
> + *   * so on non-buggy drives we need test only one.
> + *    * However, we should also check whether these fields are valid.
> + *     */
> +static inline int idedisk_supports_hpa(const struct hd_driveid *id)
> +{
> +        return (id->command_set_1 & 0x0400) && (id->cfs_enable_1 & 0x0400);
> +}
> +
>  #endif /* _IDE_H */
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>   
Ok I have it working now. The problem was that I had to call
ide_do_drive_cmd() first and then I had to call init_idedisk_capacity()
instead of idedisk_check_hpa(). Anyway im submitting the patch on the list.

Thanks,


Lee Trager

Re: Merging libata PATA support into the base kernel

[Jens Axboe]

On Thu, Aug 10 2006, Jason Lunz wrote:
> In gmane.linux.kernel, you wrote:
> > You make it sound much worse than it is. Apart for HPA, I'm not aware of
> > any setups that require extra treatment. And the amount of reported bugs
> > against it are pretty close to zero :-)
> 
> *ahem*.
> 
> I needed to do this to cure IDE hangs on resume:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc3/2.6.18-rc3-mm2/broken-out/ide-reprogram-disk-pio-timings-on-resume.patch
> 
> Are you watching the suspend mailing lists? There's no shortage of them:
> 
> suspend-devel:	http://dir.gmane.org/gmane.linux.kernel.suspend.devel
> linux-pm:	http://dir.gmane.org/gmane.linux.power-management.general
> suspend2-devel:	http://dir.gmane.org/gmane.linux.swsusp.devel
> suspend2-users:	http://dir.gmane.org/gmane.linux.swsusp.general
> 
> I'm currently trying to help out one Sheer El-Showk, whose piix ide
> requires 30 seconds of floundering followed by a bus reset to resume:
> 
> http://thread.gmane.org/gmane.linux.kernel.suspend.devel/276/focus=347
> 
> But I know next-to-nothing about ATA.
> 
> It's not surprising you're not getting many bug reports. It's common for
> several things to go wrong during s2ram, and the user often ends up
> looking at a hung system with a dead screen. It takes some quality time
> with netconsole to even begin to narrow down that it's IDE hanging the
> system, after which you can *begin* solving the no-video-on-resume
> issue.

I'm not on any of the suspend lists, I was merely comparing the
suspend-others or suspend-libata ration to suspend-ide on linux-kernel,
and the latter is clearly in the minority. I've used ide suspend quite a
bit myself, and never had issues with it (or whichever ones I saw
initially, I fixed). Of course it depends very much on the hardware. I'd
still say that ide suspend probably supports a much wider range of
hardware, than does libata suspend.

-- 
Jens Axboe

Re: Merging libata PATA support into the base kernel

[Rafael J. Wysocki]

On Thursday 10 August 2006 21:47, Jens Axboe wrote:
> On Thu, Aug 10 2006, Jason Lunz wrote:
> > In gmane.linux.kernel, you wrote:
]--snip--[
> > 
> > It's not surprising you're not getting many bug reports. It's common for
> > several things to go wrong during s2ram, and the user often ends up
> > looking at a hung system with a dead screen. It takes some quality time
> > with netconsole to even begin to narrow down that it's IDE hanging the
> > system, after which you can *begin* solving the no-video-on-resume
> > issue.
> 
> I'm not on any of the suspend lists, I was merely comparing the
> suspend-others or suspend-libata ration to suspend-ide on linux-kernel,
> and the latter is clearly in the minority. I've used ide suspend quite a
> bit myself, and never had issues with it (or whichever ones I saw
> initially, I fixed). Of course it depends very much on the hardware. I'd
> still say that ide suspend probably supports a much wider range of
> hardware, than does libata suspend.

As far as the suspend to disk is concerned, you are probably right, but
I'm not sure about the suspend to RAM.

Greetings,
Rafael

Re: Merging libata PATA support into the base kernel

[Mark Lord]

Jens Axboe wrote:
>
> I'm not on any of the suspend lists, I was merely comparing the
> suspend-others or suspend-libata ration to suspend-ide on linux-kernel,
> and the latter is clearly in the minority. I've used ide suspend quite a
> bit myself, and never had issues with it (or whichever ones I saw
> initially, I fixed). Of course it depends very much on the hardware. I'd
> still say that ide suspend probably supports a much wider range of
> hardware, than does libata suspend.

Of my various notebooks over the years that used drivers/ide,
all of them work/worked perfectly with suspend/resume to RAM.

Just luck, perhaps.

Cheers

Re: Merging libata PATA support into the base kernel

[Krzysztof Halasa]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> Jeff (rightly) thinks the plan should be discussed publically, so here
> is the plan
>
> For 2.6.19 to move the libata drivers to drivers/ata
> Add a subset of the new PATA drivers living in -mm to the base kernel

Good plan.

> Many of the new libata drivers are already more stable and functional
> than the drivers/ide ones.

Certainly.
-- 
Krzysztof Halasa

Re: Merging libata PATA support into the base kernel

[Albert Lee]

Alan Cox wrote:
> Jeff (rightly) thinks the plan should be discussed publically, so here
> is the plan
> 
> For 2.6.19 to move the libata drivers to drivers/ata
> Add a subset of the new PATA drivers living in -mm to the base kernel
> 

Is it planned for the pata_pdc2027x driver to be included in the
subset of upstream PATA drivers? It would be nice to have the driver
for the adapter hotplug on ppc64.

Thanks,

Albert

Re: Merging libata PATA support into the base kernel

[Jeff Garzik]

Albert Lee wrote:
> Alan Cox wrote:
>> Jeff (rightly) thinks the plan should be discussed publically, so here
>> is the plan
>>
>> For 2.6.19 to move the libata drivers to drivers/ata
>> Add a subset of the new PATA drivers living in -mm to the base kernel
>>
> 
> Is it planned for the pata_pdc2027x driver to be included in the
> subset of upstream PATA drivers? It would be nice to have the driver
> for the adapter hotplug on ppc64.

Yes.  That driver will go along with all the other PATA drivers in the 
#pata-drivers branch.

	Jeff

Re: Merging libata PATA support into the base kernel

[Doug Maxey]

On Wed, 23 Aug 2006 23:38:16 EDT, Jeff Garzik wrote:
> 
> Yes.  That driver will go along with all the other PATA drivers in the 
> #pata-drivers branch.

Sweet.  Does this mean pata_pdc2027x will move to upstream for the 2.6.19
merge window opening?

++doug