2.5.18 IDE 73
Quoted 4 lines
-
ide_driveid_updateis gone. We don't report the drive id through/proc/ideand we don't have to update it any longer on the fly. Still someone out there complaining that it went away!?
But the id information is still available through the ioctl interface. ide_driveid_update was used to update the dma_ultra, dma_mword, and dma_lword fields in the id structure after changing the rate with an ioctl command. Won't these fields be wrong if the rate is changed after initialization? Won't "hdparm -i" show outdated and incorrect information.
It's good to see the duplicate identify routine go away, but the ioctl shouldn't return incorrect information. Can the remaining identify routine be modified and called directly from the ioctl that returns the id information?
Gerald
Quoted 10 lines · Gerald Champagne
Quoted 2 lines
-
ide_driveid_updateis gone. We don't report the drive id through/proc/ideand we don't have to update it any longer on the fly. Still someone out there complaining that it went away!?But the id information is still available through the ioctl interface.
ide_driveid_updatewas used to update thedma_ultra,dma_mword, anddma_lwordfields in the id structure after changing the rate with an
ioctl command. Won't these fields be wrong if the rate is changed after
initialization? Won't "hdparm -i" show outdated and incorrect
information.
Quoted 6 lines
It's good to see the duplicate identify routine go away, but the ioctl shouldn't return incorrect information. Can the remaining identify routine be modified and called directly from the ioctl that returns the id information?
Gerald
Dear Gerald please look closer. The hdparm -i is executing the drive id command directly and does *not* rely on the internally permanently dragged around id structure. So the change I did is entierly fine. Just go ahead and check whatever hdparm -i /dev/hdx reports the proper thing after changing some dma setting. It does - I did check it :-).
BTW> The next thing to be gone is simple the fact that we drag around the id information permanently, where infact only some capabilitie fields are sucked out of it and the device identification string is only needed for reporting during boot-up.
Quoted 7 lines
Dear Gerald please look closer. The hdparm -i is executing the drive id command directly and does *not* rely on the internally permanently dragged around id structure. So the change I did is entierly fine. Just go ahead and check whatever hdparm -i
/dev/hdxreports the proper thing after changing some dma setting. It does - I did check it :-).
Ah, sorry about that. I missed that in your patch. The previous version of the ioctl just returned copied the values from the id structure. Doing the id on the fly is much more accurate and will catch any other fields that happen to change over time.
Quoted 5 lines
BTW> The next thing to be gone is simple the fact that we drag around the id information permanently, where infact only some capabilitie fields are sucked out of it and the device identification string is only needed for reporting during boot-up.
That sounds good. That would make it easier to see what values from the id are actually used.
Thanks.
Gerald
Quoted 2 lines · Martin Dalecki
Dear Gerald please look closer. The hdparm -i is executing the drive id command directly and does *not* rely on the internally
hdparm -i uses the HDIO_GET_IDENTITY ioctl, which returns drive->id. It doesn't obtain the ID from the drive. hdparm -I asks the identity from the drive.
hdparm --help gives some hints:
-i display drive identification
-I read drive identification directly from drive
and the man page is quite clear:
-i Display the identification info that was obtained
from the drive at boot time, if available. This is a feature of modern IDE drives, and may not be sup ported by older devices. The data returned may or may not be current, depending on activity since booting the system. However, the current multiple
sector mode count is always shown. For a more
detailed interpretation of the identification info, refer to AT Attachment Interface for Disk Drives (ANSI ASC X3T9.2 working draft, revision 4a, April 19/93).
-I Request identification info directly from the
drive, which is displayed in its raw form with no
endian changes or corrections. Text strings may
appear mangled when using -I but that is NOT a bug. Otherwise similar to the -i option.
Signature · 2 lines
Russell King ([email protected]) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html
Quoted 9 lines · Russell King
Quoted 2 lines · Martin Dalecki
Dear Gerald please look closer. The hdparm -i is executing the drive id command directly and does *not* rely on the internally
hdparm -i uses the
HDIO_GET_IDENTITYioctl, which returnsdrive->id. It doesn't obtain the ID from the drive. hdparm -I asks the identity from the drive.
Yes. But this will be just changed soon, since there
is no reaons at all to don't just read it always from the drive, in esp. in face of the above.
BTW.> The above function was only used when the user invoked ioctl() - that was my point.
Quoted 25 lines
hdparm --help gives some hints:
-i display drive identification
-I read drive identification directly from driveand the man page is quite clear:
-i Display the identification info that was obtained
from the drive at boot time, if available. This is a feature of modern IDE drives, and may not be sup ported by older devices. The data returned may or may not be current, depending on activity since booting the system. However, the current multiple
sector mode count is always shown. For a more
detailed interpretation of the identification info, refer to AT Attachment Interface for Disk Drives (ANSI ASC X3T9.2 working draft, revision 4a, April 19/93).-I Request identification info directly from the
drive, which is displayed in its raw form with no
endian changes or corrections. Text strings may
appear mangled when using -I but that is NOT a bug. Otherwise similar to the -i option.
Signature · 3 lines
- phone: +49 214 8656 283 - job: eVision-Ventures AG, LEV .de (MY OPINIONS ARE MY OWN!) - langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R
Quoted 5 lines · Martin Dalecki
BTW> The next thing to be gone is simple the fact that we drag around the id information permanently, where infact only some capabilitie fields are sucked out of it and the device identification string is only needed for reporting during boot-up.
Also for black/whitelists. And we're going to need those, though maybe the current data in them is not worth much.
Signature · 2 lines
Vojtech Pavlik SuSE Labs
Quoted 2 lines · Vojtech Pavlik
Also for black/whitelists. And we're going to need those, though maybe the current data in them is not worth much.
I'm hopeful they still are. The early drives with DMA problems won't have changed over time, and I've been updating the others when I get data from vendors. Promise for example recently sent me a couple to add
Quoted 10 lines · Vojtech Pavlik
Quoted 5 lines · Martin Dalecki
BTW> The next thing to be gone is simple the fact that we drag around the id information permanently, where infact only some capabilitie fields are sucked out of it and the device identification string is only needed for reporting during boot-up.
Quoted 2 lines
Also for black/whitelists. And we're going to need those, though maybe the current data in them is not worth much.
Indeed thanks for the reminder. However as far as I'm concerned I would rather agree that the data currently present in those black/whitelists is basically useless. Most of the disks present there are simple plain just obsoleted by a great margin or have already dyed due to the severe firmware errors they did contain. And finally this data was basically collected during the fortunately long bast days where cmd64x chips where prevalent on VLB 486 systems. It's most propably not accurate for more modenr ATA host chip cells.
Quoted 4 lines · Martin Dalecki
Indeed thanks for the reminder. However as far as I'm concerned I would rather agree that the data currently present in those black/whitelists is basically useless. Most of the disks present there are simple plain just obsoleted by a great margin
Lots of people are still using them. Removing the blacklists "because they are old disks" is not what I'd consider good practice.
Quoted 1 line
It's most propably not accurate for more modenr ATA host chip cells.
For the DMA blacklists thats not the case. You need to get more direct contacts with the IDE/ATA drive vendors and documentation sets. The WDC DMA blacklist entries for example are from specific WDC issued lists of problem drives.
Alan
On the subject of blacklists -- when downgrading the speed of a drive because it's found a blacklist, or indeed for any other reason, please _print_ the reason for doing so.
I have drives which work fine at UDMA66, but which some kernels randomly refuse to configure above UDMA33 without telling me why.
Basically, any time you run a drive at a transfer speed lower than the minimum of the drive's and host's listed capabilities, you should say why you're doing so.
--
dwmw2
Quoted 3 lines · David Woodhouse
On the subject of blacklists -- when downgrading the speed of a drive because it's found a blacklist, or indeed for any other reason, please _print_ the reason for doing so.
I have drives which work fine at UDMA66, but which some kernels randomly refuse to configure above UDMA33 without telling me why.
Which are those ones on which controller configuration?
Quoted 2 lines
Basically, any time you run a drive at a transfer speed lower than the minimum of the drive's and host's listed capabilities, you should say why you're doing so.
Sure just let do one steop after other OK.
Quoted 6 lines · Alan Cox
Quoted 2 lines
Also for black/whitelists. And we're going to need those, though maybe the current data in them is not worth much.
I'm hopeful they still are. The early drives with DMA problems won't have changed over time, and I've been updating the others when I get data from vendors. Promise for example recently sent me a couple to add
The early drives haven't changed, but the drivers for the controllers which they were tested on changed (or will change soon). Namely the lists of PIO mode limits were wrong very often. This is mainly because some of the (now almost unused) drivers program the timings incorrectly into the controller registers.
I can't say much about the more recent entries, except for that it'd be nice to add a date when the entry was last tested and with what result to each of them over time.
Signature · 2 lines
Vojtech Pavlik SuSE Labs
Quoted 5 lines · Vojtech Pavlik
The early drives haven't changed, but the drivers for the controllers which they were tested on changed (or will change soon). Namely the lists of PIO mode limits were wrong very often. This is mainly because some of the (now almost unused) drivers program the timings incorrectly into the controller registers.
Ok I'm not sure on the PIO ones. The DMA blacklist is a set of devices that had actual firmware side problems on the whole and vendor confirmed ones.
Quoted 3 lines
I can't say much about the more recent entries, except for that it'd be nice to add a date when the entry was last tested and with what result to each of them over time.
The ones I have are from vendors whom I hope know what they are doing. The one exception is an item which is missing which is the needed blacklist of UDMA on the OSB4 for one vendor at least (MWDMA is fine)
Quoted 17 lines · Vojtech Pavlik
Quoted 6 lines · Alan Cox
Quoted 2 lines
Also for black/whitelists. And we're going to need those, though maybe the current data in them is not worth much.
I'm hopeful they still are. The early drives with DMA problems won't have changed over time, and I've been updating the others when I get data from vendors. Promise for example recently sent me a couple to add
The early drives haven't changed, but the drivers for the controllers which they were tested on changed (or will change soon). Namely the lists of PIO mode limits were wrong very often. This is mainly because some of the (now almost unused) drivers program the timings incorrectly into the controller registers.
Quoted 3 lines
I can't say much about the more recent entries, except for that it'd be nice to add a date when the entry was last tested and with what result to each of them over time.
And plese note as well that we don't need the whole id struct, but just the name of the drive as well. Which is much less of a hassle anyway.
Quoted 18 lines · Martin Dalecki
Quoted 17 lines · Vojtech Pavlik
Quoted 6 lines · Alan Cox
Quoted 2 lines
Also for black/whitelists. And we're going to need those, though maybe the current data in them is not worth much.
I'm hopeful they still are. The early drives with DMA problems won't have changed over time, and I've been updating the others when I get data from vendors. Promise for example recently sent me a couple to add
The early drives haven't changed, but the drivers for the controllers which they were tested on changed (or will change soon). Namely the lists of PIO mode limits were wrong very often. This is mainly because some of the (now almost unused) drivers program the timings incorrectly into the controller registers.
Quoted 6 lines
Quoted 3 lines
I can't say much about the more recent entries, except for that it'd be nice to add a date when the entry was last tested and with what result to each of them over time.
And plese note as well that we don't need the whole id struct, but just the name of the drive as well. Which is much less of a hassle anyway.
Correct. And the manufacturer and the revision.
Signature · 2 lines
Vojtech Pavlik SuSE Labs