[PATCH] Re: [PATCH] IDE clean 12 3rd attempt

[PATCH] Re: [PATCH] IDE clean 12 3rd attempt

[Andries.Brouwer]

> Since this apparently didn't get through to the mailing list
> I'm sending it again. This time compressed.

Pity - noncompressed is better, now only people with too much time
will look at it.

There is something else one might do.
In ide-geometry.c there is the routine probe_cmos_for_drives().
Long ago I already wrote "Eventually the entire routine below
should be removed". I think this is the proper time to do this.

This probe is done only for the i386 architecture, and only
for the first two IDE disks, and only influences their geometry.
It has been a pain - for example, it gives the first two disks
a different geometry from the others, which is inconvenient
when one want a RAID of identical disks.

So, it is good to rip this out and push the inconvenience to
people with ancient hardware. (People with MFM disks may need
boot parameters now.)
When this is gone, much more can go, both in the IDE code and
in setup.S.

Andries


diff -u ../linux-2.5.5/linux/drivers/ide/ide-geometry.c linux/drivers/ide/ide-geometry.c
--- ../linux-2.5.5/linux/drivers/ide/ide-geometry.c	Sun Feb  3 12:35:52 2002
+++ linux/drivers/ide/ide-geometry.c	Mon Feb 25 15:18:09 2002
@@ -6,89 +6,6 @@
 #include <linux/mc146818rtc.h>
 #include <asm/io.h>
 
-#ifdef CONFIG_BLK_DEV_IDE
-
-/*
- * We query CMOS about hard disks : it could be that we have a SCSI/ESDI/etc
- * controller that is BIOS compatible with ST-506, and thus showing up in our
- * BIOS table, but not register compatible, and therefore not present in CMOS.
- *
- * Furthermore, we will assume that our ST-506 drives <if any> are the primary
- * drives in the system -- the ones reflected as drive 1 or 2.  The first
- * drive is stored in the high nibble of CMOS byte 0x12, the second in the low
- * nibble.  This will be either a 4 bit drive type or 0xf indicating use byte
- * 0x19 for an 8 bit type, drive 1, 0x1a for drive 2 in CMOS.  A non-zero value
- * means we have an AT controller hard disk for that drive.
- *
- * Of course, there is no guarantee that either drive is actually on the
- * "primary" IDE interface, but we don't bother trying to sort that out here.
- * If a drive is not actually on the primary interface, then these parameters
- * will be ignored.  This results in the user having to supply the logical
- * drive geometry as a boot parameter for each drive not on the primary i/f.
- */
-/*
- * The only "perfect" way to handle this would be to modify the setup.[cS] code
- * to do BIOS calls Int13h/Fn08h and Int13h/Fn48h to get all of the drive info
- * for us during initialization.  I have the necessary docs -- any takers?  -ml
- */
-/*
- * I did this, but it doesnt work - there is no reasonable way to find the
- * correspondence between the BIOS numbering of the disks and the Linux
- * numbering. -aeb
- *
- * The code below is bad. One of the problems is that drives 1 and 2
- * may be SCSI disks (even when IDE disks are present), so that
- * the geometry we read here from BIOS is attributed to the wrong disks.
- * Consequently, also the former "drive->present = 1" below was a mistake.
- *
- * Eventually the entire routine below should be removed.
- *
- * 17-OCT-2000 rjohnson@analogic.com Added spin-locks for reading CMOS
- * chip.
- */
-
-void probe_cmos_for_drives (ide_hwif_t *hwif)
-{
-#ifdef __i386__
-	extern struct drive_info_struct drive_info;
-	byte cmos_disks, *BIOS = (byte *) &drive_info;
-	int unit;
-	unsigned long flags;
-
-#ifdef CONFIG_BLK_DEV_PDC4030
-	if (hwif->chipset == ide_pdc4030 && hwif->channel != 0)
-		return;
-#endif /* CONFIG_BLK_DEV_PDC4030 */
-	spin_lock_irqsave(&rtc_lock, flags);
-	cmos_disks = CMOS_READ(0x12);
-	spin_unlock_irqrestore(&rtc_lock, flags);
-	/* Extract drive geometry from CMOS+BIOS if not already setup */
-	for (unit = 0; unit < MAX_DRIVES; ++unit) {
-		ide_drive_t *drive = &hwif->drives[unit];
-
-		if ((cmos_disks & (0xf0 >> (unit*4)))
-		   && !drive->present && !drive->nobios) {
-			unsigned short cyl = *(unsigned short *)BIOS;
-			unsigned char head = *(BIOS+2);
-			unsigned char sect = *(BIOS+14);
-			if (cyl > 0 && head > 0 && sect > 0 && sect < 64) {
-				drive->cyl   = drive->bios_cyl  = cyl;
-				drive->head  = drive->bios_head = head;
-				drive->sect  = drive->bios_sect = sect;
-				drive->ctl   = *(BIOS+8);
-			} else {
-				printk("hd%c: C/H/S=%d/%d/%d from BIOS ignored\n",
-				       unit+'a', cyl, head, sect);
-			}
-		}
-
-		BIOS += 16;
-	}
-#endif
-}
-#endif /* CONFIG_BLK_DEV_IDE */
-
-
 #if defined(CONFIG_BLK_DEV_IDE) || defined(CONFIG_BLK_DEV_IDE_MODULE)
 
 extern ide_drive_t * get_info_ptr(kdev_t);
diff -u ../linux-2.5.5/linux/drivers/ide/ide-probe.c linux/drivers/ide/ide-probe.c
--- ../linux-2.5.5/linux/drivers/ide/ide-probe.c	Thu Feb 21 23:50:02 2002
+++ linux/drivers/ide/ide-probe.c	Mon Feb 25 15:18:45 2002
@@ -509,13 +509,6 @@
 
 	if (hwif->noprobe)
 		return;
-#ifdef CONFIG_BLK_DEV_IDE
-	if (hwif->io_ports[IDE_DATA_OFFSET] == HD_DATA) {
-		extern void probe_cmos_for_drives(ide_hwif_t *);
-
-		probe_cmos_for_drives (hwif);
-	}
-#endif
 
 	if ((hwif->chipset != ide_4drives || !hwif->mate->present) &&
 #if CONFIG_BLK_DEV_PDC4030

Re: [PATCH] Re: [PATCH] IDE clean 12 3rd attempt

[Martin Dalecki]

Andries.Brouwer@cwi.nl wrote:
>>Since this apparently didn't get through to the mailing list
>>I'm sending it again. This time compressed.
>>
> 
> Pity - noncompressed is better, now only people with too much time
> will look at it.
> 
> There is something else one might do.
> In ide-geometry.c there is the routine probe_cmos_for_drives().
> Long ago I already wrote "Eventually the entire routine below
> should be removed". I think this is the proper time to do this.
> 
> This probe is done only for the i386 architecture, and only
> for the first two IDE disks, and only influences their geometry.
> It has been a pain - for example, it gives the first two disks
> a different geometry from the others, which is inconvenient
> when one want a RAID of identical disks.
>
Basically I lend toward your arguments. I think too that a bios based
detection is already right and then we have now the ide-skip kernel
parameter which is allowing to exclude a drive from handling by the 
linux ide driver anyway. And I think that 2.4.x and above don't run on
i386's anymore anyway.

Re: [PATCH] Re: [PATCH] IDE clean 12 3rd attempt

[arjan]

In article <3C79435E.8030208@evision-ventures.com> you wrote:

> linux ide driver anyway. And I think that 2.4.x and above don't run on
> i386's anymore anyway.

it was about the i386 architecture, not just 80386 cpus. And yes 2.4 still
runs on those; you'be surprised how many
embedded systems run 80386 equivalents...

Re: [PATCH] Re: [PATCH] IDE clean 12 3rd attempt

[Martin Dalecki]

arjan@fenrus.demon.nl wrote:
> In article <3C79435E.8030208@evision-ventures.com> you wrote:
> 
> 
>>linux ide driver anyway. And I think that 2.4.x and above don't run on
>>i386's anymore anyway.
>>
> 
> it was about the i386 architecture, not just 80386 cpus. And yes 2.4 still
> runs on those; you'be surprised how many
> embedded systems run 80386 equivalents...

Interresting. But do they still incorporate ST509 and other
archaic controllers? Or do they have broken BIOS-es which don't
setup the geometry information properly? I don't think so.

Well now I'm quite convinced. We can point those people to the legacy
single host driver anyway... And then the tradeoff goes just in favour
of supporting more and more common new hardware - it will just make
more people happy than it will make people loose :-).

Re: [PATCH] Re: [PATCH] IDE clean 12 3rd attempt

[Eric Krout]

> Andries.Brouwer@cwi.nl wrote:
> And I think that 2.4.x and above don't run on
> i386's anymore anyway.

I don't mean to intrude or offend, but please backup your claims with
hard facts as opposed to mere suppositions.

Re: [PATCH] Re: [PATCH] IDE clean 12 3rd attempt

[Alan Cox]

> > Andries.Brouwer@cwi.nl wrote:
> > And I think that 2.4.x and above don't run on
> > i386's anymore anyway.
> 
> I don't mean to intrude or offend, but please backup your claims with
> hard facts as opposed to mere suppositions.

2.4 runs on an i386

Re: [PATCH] Re: [PATCH] IDE clean 12 3rd attempt

[Arjan van de Ven]

On Sun, Feb 24, 2002 at 09:02:33PM +0100, Martin Dalecki wrote:
> > 
> > it was about the i386 architecture, not just 80386 cpus. And yes 2.4 still
> > runs on those; you'be surprised how many
> > embedded systems run 80386 equivalents...
> 
> Interresting. But do they still incorporate ST509 and other
> archaic controllers? Or do they have broken BIOS-es which don't
> setup the geometry information properly? I don't think so.

You bet that embedded systems use controllers that emulate archaic ones.
Oh and bios.... well...... 

> Well now I'm quite convinced. We can point those people to the legacy
> single host driver anyway... And then the tradeoff goes just in favour
> of supporting more and more common new hardware - it will just make
> more people happy than it will make people loose :-).

If you drop hardware support for no good reason.... you scare me. you
really do. Now dropping hardware support (or moving support
elsewhere) isn't always avoidable, but I'd think you need a pretty
good reason to do so. 

Re: [PATCH] Re: [PATCH] IDE clean 12 3rd attempt

[Vojtech Pavlik]

On Sun, Feb 24, 2002 at 09:02:33PM +0100, Martin Dalecki wrote:
> arjan@fenrus.demon.nl wrote:
> > In article <3C79435E.8030208@evision-ventures.com> you wrote:
> > 
> > 
> >>linux ide driver anyway. And I think that 2.4.x and above don't run on
> >>i386's anymore anyway.
> >>
> > 
> > it was about the i386 architecture, not just 80386 cpus. And yes 2.4 still
> > runs on those; you'be surprised how many
> > embedded systems run 80386 equivalents...
> 
> Interresting. But do they still incorporate ST509 and other
> archaic controllers? Or do they have broken BIOS-es which don't
> setup the geometry information properly? I don't think so.

Actually you cannot connect an IDE drive to a ST509 harddrive
controller. So that isn't handled by the IDE driver anyway and the
change won't affect people using ST509 controllers.

> Well now I'm quite convinced. We can point those people to the legacy
> single host driver anyway...

They have to use it anyway.

> And then the tradeoff goes just in favour of supporting more and more
> common new hardware - it will just make more people happy than it will
> make people loose :-).

-- 
Vojtech Pavlik
SuSE Labs

Re: [PATCH] Re: [PATCH] IDE clean 12 3rd attempt

[Martin Dalecki]

Arjan van de Ven wrote:
> On Sun, Feb 24, 2002 at 09:02:33PM +0100, Martin Dalecki wrote:
> 
>>>it was about the i386 architecture, not just 80386 cpus. And yes 2.4 still
>>>runs on those; you'be surprised how many
>>>embedded systems run 80386 equivalents...
>>>
>>Interresting. But do they still incorporate ST509 and other
>>archaic controllers? Or do they have broken BIOS-es which don't
>>setup the geometry information properly? I don't think so.
>>
> 
> You bet that embedded systems use controllers that emulate archaic ones.
> Oh and bios.... well...... 
> 
> 
>>Well now I'm quite convinced. We can point those people to the legacy
>>single host driver anyway... And then the tradeoff goes just in favour
>>of supporting more and more common new hardware - it will just make
>>more people happy than it will make people loose :-).
>>
> 
> If you drop hardware support for no good reason.... you scare me. you
> really do. Now dropping hardware support (or moving support
> elsewhere) isn't always avoidable, but I'd think you need a pretty
> good reason to do so.

Yes right. But first please really really think again what ST509 and MFM
controllers are ;-). And after all I have already heard some time
before some real complains from real users around me about the
particular behaviour currently present, which tried to use software raid 
on ATA disks. And after all please have a look at the note from Andires 
inside the patch, which has been there for a long time now.

Hmm I will perhaps have just to check what distro-backed-kernels do
here... Becouse if my memmory is right, they are removing this 
particular function too already...

If you have any objections please *point me* at a particular system
where this would really break things.

Re: [PATCH] Re: [PATCH] IDE clean 12 3rd attempt

[Andries.Brouwer]

>> Andries.Brouwer@cwi.nl wrote:
>> And I think that 2.4.x and above don't run on
>> i386's anymore anyway.

> I don't mean to intrude or offend, but please backup your claims
> with hard facts as opposed to mere suppositions.

Please have the decency to ascribe your quotes to the correct people.

Re: [PATCH] Re: [PATCH] IDE clean 12 3rd attempt

[Andries.Brouwer]

Arjan van de Ven writes:

> Martin Dalecki wrote:

>> Interresting. But do they still incorporate ST509 ..

> If you drop hardware support for no good reason.... you scare me.

Arjan - in this particular case, are you just shouting random things?
Or have you looked at the patch, and understood what it does?

Andries

Re: [PATCH] Re: [PATCH] IDE clean 12 3rd attempt

[Paul Gortmaker]

Andries.Brouwer@cwi.nl wrote:

> There is something else one might do.
> In ide-geometry.c there is the routine probe_cmos_for_drives().
> Long ago I already wrote "Eventually the entire routine below
> should be removed". I think this is the proper time to do this.

Yes, I saw this & looked over my mail - we had similar discussion
& similar conclusion back in May 2000.  (Others may also find aeb's
notes from this old discussion useful - check the archives)

> So, it is good to rip this out and push the inconvenience to
> people with ancient hardware. (People with MFM disks may need
> boot parameters now.)

As a matter of fact, they would have needed to do so even since
2.3.28, when drive->present was no longer set.  Also from that
2 year old discussion is this patch to set capacity for non-IDE
drives. Fact is that ST-506 would even to this day not work with 
the ide driver without this patch. (Of course using hd.c on ST-506
era machines makes a lot more sense anyways, so this is pretty
much moot.)

Paul.

diff -u linux-r/drivers/ide-old/ide-disk.c linux-r/drivers/ide/ide-disk.c
--- linux-r/drivers/ide-old/ide-disk.c	Fri May 26 16:37:43 2000
+++ linux-r/drivers/ide/ide-disk.c	Sat May 27 14:33:27 2000
@@ -519,7 +519,6 @@
 
 /*
  * Compute drive->capacity, the full capacity of the drive
- * Called with drive->id != NULL.
  */
 static void init_idedisk_capacity (ide_drive_t  *drive)
 {
@@ -529,7 +528,7 @@
 	drive->select.b.lba = 0;
 
 	/* Determine capacity, and use LBA if the drive properly supports it */
-	if ((id->capability & 2) && lba_capacity_is_ok(id)) {
+	if (id != NULL && (id->capability & 2) && lba_capacity_is_ok(id)) {
 		capacity = id->lba_capacity;
 		drive->cyl = capacity / (drive->head * drive->sect);
 		drive->select.b.lba = 1;
@@ -759,8 +758,10 @@
 	
 	idedisk_add_settings(drive);
 
-	if (id == NULL)
+	if (id == NULL) {	/* Old, non-IDE drive */
+		init_idedisk_capacity(drive);
 		return;
+	}
 
 	/*
 	 * CompactFlash cards and their brethern look just like hard drives

Re: [PATCH] Re: [PATCH] IDE clean 12 3rd attempt

[Martin Dalecki]

Paul Gortmaker wrote:
> Andries.Brouwer@cwi.nl wrote:
> 
> 
>>There is something else one might do.
>>In ide-geometry.c there is the routine probe_cmos_for_drives().
>>Long ago I already wrote "Eventually the entire routine below
>>should be removed". I think this is the proper time to do this.
>>
> 
> Yes, I saw this & looked over my mail - we had similar discussion
> & similar conclusion back in May 2000.  (Others may also find aeb's
> notes from this old discussion useful - check the archives)
> 
> 
>>So, it is good to rip this out and push the inconvenience to
>>people with ancient hardware. (People with MFM disks may need
>>boot parameters now.)
>>
> 
> As a matter of fact, they would have needed to do so even since
> 2.3.28, when drive->present was no longer set.  Also from that
> 2 year old discussion is this patch to set capacity for non-IDE
> drives. Fact is that ST-506 would even to this day not work with 
> the ide driver without this patch. (Of course using hd.c on ST-506
> era machines makes a lot more sense anyways, so this is pretty
> much moot.)
> 
> Paul.

I have already applied the CMOS probe removal patch to my personal tree
and it turns out any obvious things. However I still don't see how it 
may simplify the ide.c code further...

to indeed not break

> 
> diff -u linux-r/drivers/ide-old/ide-disk.c linux-r/drivers/ide/ide-disk.c
> --- linux-r/drivers/ide-old/ide-disk.c	Fri May 26 16:37:43 2000
> +++ linux-r/drivers/ide/ide-disk.c	Sat May 27 14:33:27 2000
> @@ -519,7 +519,6 @@
>  
>  /*
>   * Compute drive->capacity, the full capacity of the drive
> - * Called with drive->id != NULL.
>   */
>  static void init_idedisk_capacity (ide_drive_t  *drive)
>  {
> @@ -529,7 +528,7 @@
>  	drive->select.b.lba = 0;
>  
>  	/* Determine capacity, and use LBA if the drive properly supports it */
> -	if ((id->capability & 2) && lba_capacity_is_ok(id)) {
> +	if (id != NULL && (id->capability & 2) && lba_capacity_is_ok(id)) {
>  		capacity = id->lba_capacity;
>  		drive->cyl = capacity / (drive->head * drive->sect);
>  		drive->select.b.lba = 1;
> @@ -759,8 +758,10 @@
>  	
>  	idedisk_add_settings(drive);
>  
> -	if (id == NULL)
> +	if (id == NULL) {	/* Old, non-IDE drive */
> +		init_idedisk_capacity(drive);
>  		return;
> +	}
>  
>  	/*
>  	 * CompactFlash cards and their brethern look just like hard drives
> 
> 
> 



-- 
- 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

Re: [PATCH] Re: [PATCH] IDE clean 12 3rd attempt

[Pavel Machek]

Hi!

> >Pity - noncompressed is better, now only people with too much time
> >will look at it.
> >
> >There is something else one might do.
> >In ide-geometry.c there is the routine probe_cmos_for_drives().
> >Long ago I already wrote "Eventually the entire routine below
> >should be removed". I think this is the proper time to do this.
> >
> >This probe is done only for the i386 architecture, and only
> >for the first two IDE disks, and only influences their geometry.
> >It has been a pain - for example, it gives the first two disks
> >a different geometry from the others, which is inconvenient
> >when one want a RAID of identical disks.
> >
> Basically I lend toward your arguments. I think too that a bios based
> detection is already right and then we have now the ide-skip kernel
> parameter which is allowing to exclude a drive from handling by the 
> linux ide driver anyway. And I think that 2.4.x and above don't run on
> i386's anymore anyway.

I sure hope they do.

I run 2.4.x on 486sx, which is .... pretty close to 386. 386 support
is not going to get dropped anytime soon...
									Pavel
-- 
(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa

Re: [PATCH] Re: [PATCH] IDE clean 12 3rd attempt

[Martin Dalecki]

Pavel Machek wrote:
> I sure hope they do.
> 
> I run 2.4.x on 486sx, which is .... pretty close to 386. 386 support
> is not going to get dropped anytime soon...

Well the 486sx is the same die as 486 with coproc disabled. And in
contrast the the 386 the 486 is a scalar, tough not super-scalar CPU.
(This is what this "pipline stuff" and multiple pipeline stuff is about ;-).

Please trust me they are *not* very similar from CPU design point
of view. They are only similar on the command set level.
Anyway just to put it straight: Your system certainly won't be affected
by the removal.

Re: [PATCH] Re: [PATCH] IDE clean 12 3rd attempt

[Jeff Garzik]

Martin Dalecki wrote:
> Pavel Machek wrote:
> > I run 2.4.x on 486sx, which is .... pretty close to 386. 386 support
> > is not going to get dropped anytime soon...

> Well the 486sx is the same die as 486 with coproc disabled. And in
> contrast the the 386 the 486 is a scalar, tough not super-scalar CPU.
> (This is what this "pipline stuff" and multiple pipeline stuff is about ;-).
> 
> Please trust me they are *not* very similar from CPU design point
> of view. They are only similar on the command set level.
> Anyway just to put it straight: Your system certainly won't be affected
> by the removal.

Regardless, 386 support should not go away...

-- 
Jeff Garzik      | "UNIX enhancements aren't."
Building 1024    |           -- says /usr/games/fortune
MandrakeSoft     |

Re: [PATCH] Re: [PATCH] IDE clean 12 3rd attempt

[Martin Dalecki]

Jeff Garzik wrote:
> Martin Dalecki wrote:
> 
>>Pavel Machek wrote:
>>
>>>I run 2.4.x on 486sx, which is .... pretty close to 386. 386 support
>>>is not going to get dropped anytime soon...
>>>
> 
>>Well the 486sx is the same die as 486 with coproc disabled. And in
>>contrast the the 386 the 486 is a scalar, tough not super-scalar CPU.
>>(This is what this "pipline stuff" and multiple pipeline stuff is about ;-).
>>
>>Please trust me they are *not* very similar from CPU design point
>>of view. They are only similar on the command set level.
>>Anyway just to put it straight: Your system certainly won't be affected
>>by the removal.
>>
> 
> Regardless, 386 support should not go away...

It won't! The issue does have nothing to do with the CPU in
the system. What goes away is a misguided attempt to treat an
AT computer like a 8088 class early PC. OK?