public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* IDE-flash device and hard disk on same controller
@ 2002-08-19 18:31 Heater, Daniel (IndSys, GEFanuc, VMIC)
  2002-08-19 19:21 ` Alan Cox
  2002-08-20  8:44 ` Padraig Brady
  0 siblings, 2 replies; 43+ messages in thread
From: Heater, Daniel (IndSys, GEFanuc, VMIC) @ 2002-08-19 18:31 UTC (permalink / raw)
  To: 'Linux Kernel'
  Cc: 'andre@linux-ide.org',
	Warner, Bill (IndSys, GEFanuc, VMIC)


The IDE driver, file ide-probe.c currently contains this test do prevent
hard drives and IDE-flash devices (ex CompactFlash) from co-existing on the
same IDE controller. 

        /*
         * Prevent long system lockup probing later for non-existant
         * slave drive if the hwif is actually a flash memory card of some
variety:
         */
        if (drive_is_flashcard(drive)) {
                ide_drive_t *mate =
&HWIF(drive)->drives[1^drive->select.b.unit];
                if (!mate->ata_flash) {
                        mate->present = 0;
                        mate->noprobe = 1;
                }
        }

This test's assumption that a spinning hard drive cannot coexist on the same
controller as an IDE-flash device is incorrect.  I have a working setup with
such a configuration.  I don't think that the IDE subsystem should punish
everyone because _some_ hardware cannot tolerate this configuration.

One solution may be to remove this test from the IDE subsystem and force
users with buggy hardware to explicitly  disable probing for a second
device.  I think the parameters hdx=none or hdx=noprobe should work for
them.

Comments??



^ permalink raw reply	[flat|nested] 43+ messages in thread
* RE: IDE-flash device and hard disk on same controller
@ 2002-08-20 19:52 Heater, Daniel (IndSys, GEFanuc, VMIC)
  2002-08-20 21:57 ` Andre Hedrick
  2002-08-22 13:41 ` bill davidsen
  0 siblings, 2 replies; 43+ messages in thread
From: Heater, Daniel (IndSys, GEFanuc, VMIC) @ 2002-08-20 19:52 UTC (permalink / raw)
  To: 'Padraig Brady'
  Cc: 'Linux Kernel', 'andre@linux-ide.org',
	Warner, Bill (IndSys, GEFanuc, VMIC)

> Heater, Daniel (IndSys, GEFanuc, VMIC) wrote:
> > The IDE driver, file ide-probe.c currently contains this 
> test do prevent
> > hard drives and IDE-flash devices (ex CompactFlash) from 
> co-existing on the
> > same IDE controller. 
> > 
> >         /*
> >          * Prevent long system lockup probing later for non-existant
> >          * slave drive if the hwif is actually a flash 
> memory card of some
> > variety:
> >          */
> >         if (drive_is_flashcard(drive)) {
> >                 ide_drive_t *mate =
> > &HWIF(drive)->drives[1^drive->select.b.unit];
> >                 if (!mate->ata_flash) {
> >                         mate->present = 0;
> >                         mate->noprobe = 1;
> >                 }
> >         }
> > 
> > This test's assumption that a spinning hard drive cannot 
> coexist on the same
> > controller as an IDE-flash device is incorrect.  I have a 
> working setup with
> > such a configuration.  I don't think that the IDE subsystem 
> should punish
> > everyone because _some_ hardware cannot tolerate this configuration.
> > 
> > One solution may be to remove this test from the IDE 
> subsystem and force
> > users with buggy hardware to explicitly  disable probing 
> for a second
> > device.  I think the parameters hdx=none or hdx=noprobe 
> should work for
> > them.
> > 
> > Comments??
> 
> Mentioned several times (and there is a workaround), see:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=100446144028502&w=2
> 
> I really think some of the default CF logic is bogus.
> 
> Pádraig.
> 


OK. hdc=flash works where hdc=hard drive and hdd=CompactFlash.

Thanks Padraig.

I guess it's 6 of one, half-dozen the other, but telling the kernel that my
hard drive is a flash drive just makes me feel squidgy!  I'm still inclined
to suggest that the test that _prevents_ hard drive + CF configuration is no
longer appropriate now that _some_ (most??) hardware vendors have figured
out how to get ide-flash devices to work without "hanging" when no second
device is present. Users with incompatible hardware can still prevent the
long system hang by using hdx=none.

I also used this workaround (hdb=flash) to configure a system with hda=flash
and hdb=cdrom.  This seems to work also.  Are there any side effects to
telling the kernel that the hard drive or cdrom is a flash device (such as
marking it removable or not marking it removable)?

^ permalink raw reply	[flat|nested] 43+ messages in thread
* RE: IDE-flash device and hard disk on same controller
@ 2002-08-21 13:22 Warner, Bill (IndSys, GEFanuc, VMIC)
  0 siblings, 0 replies; 43+ messages in thread
From: Warner, Bill (IndSys, GEFanuc, VMIC) @ 2002-08-21 13:22 UTC (permalink / raw)
  To: 'Geert Uytterhoeven', Andre Hedrick
  Cc: Jeff Garzik, Heater, Daniel (IndSys, GEFanuc, VMIC),
	'Padraig Brady', 'Linux Kernel',
	Warner, Bill (IndSys, GEFanuc, VMIC)

Please take me off of this discussion thread.

Thank you.

> Bill Warner  , CPU Design Engineer
VMIC    A GE Fanuc Company
> bill.warner@gefanuc.com  
> VMIC - A GE Fanuc Company
> 12090 S. Memorial Pkwy, Huntsville, AL 35803
> ph (256) 382-8230, fax (256) 650-5472                    
> 
> -----Original Message-----
> From:	Geert Uytterhoeven [SMTP:geert@linux-m68k.org]
> Sent:	Wednesday, August 21, 2002 2:17 AM
> To:	Andre Hedrick
> Cc:	Jeff Garzik; Heater, Daniel (IndSys, GEFanuc, VMIC); 'Padraig
> Brady'; 'Linux Kernel'; Warner, Bill (IndSys, GEFanuc, VMIC)
> Subject:	Re: IDE-flash device and hard disk on same controller
> 
> On Tue, 20 Aug 2002, Andre Hedrick wrote:
> > Look at 2.4.20-pre2-ac5.
> > 
> > I fixed that problem.
> 
> OK, thanks!
> 
> > On Wed, 21 Aug 2002, Geert Uytterhoeven wrote:
> > > On Tue, 20 Aug 2002, Jeff Garzik wrote:
> > > > Jeff Garzik wrote:
> > > > > Attached is the ATA core...
> > > > 
> > > > Just to give a little bit more information about the previously
> attached 
> > > > code, it is merely a module that does two things:  (a) demonstrates 
> > > > proper [and sometimes faster-than-current-linus] ATA bus probing,
> and 
> > > > (b) demonstrates generic registration and initialization of ATA
> devices 
> > > > and channels.  All other tasks can be left to "personality" (a.k.a. 
> > > > class) drivers, such as 'disk', 'cdrom', 'floppy', ... types.
> > > 
> > > Looks nice (at first sight)!
> > > 
> > > But one limitation is that it always assumes the IDE ports are located
> in I/O
> > > space :-(
> > > What about architectures where IDE ports are located in MMIO space? Or
> worse,
> > > have some ports in I/O space (e.g. PCI IDE card) and some in MMIO
> space (e.g.
> > > SOC or mainboard IDE host interface)?
> 
> Gr{oetje,eeting}s,
> 
> 						Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker.
> But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> 							    -- Linus
> Torvalds

^ permalink raw reply	[flat|nested] 43+ messages in thread
* Re: IDE-flash device and hard disk on same controller
@ 2002-08-23  6:54 Adam J. Richter
  2002-08-23  7:45 ` Andre Hedrick
  0 siblings, 1 reply; 43+ messages in thread
From: Adam J. Richter @ 2002-08-23  6:54 UTC (permalink / raw)
  To: jgarzik; +Cc: ebiederm, linux-kernel

Jeff Garzik wrote:
>Eric W. Biederman wrote:
>>The problem is that immediately after bootup ATA devices do not respond until
>>their media has spun up.  Which is both required by the spec, and observed in
>>practice.   Which is likely a problem if this code is run a few seconds after
>>bootup.  Which makes it quite possible the drive will ignore the
>>EXECUTE DEVICEDIAGNOSTICS and your error code won't be valid when 
>>the bsy flag clears.   I don't know how serious that would be. 
>
>
>Well, this only applies if you are slack and letting the kernel init 
>your ATA from scratch, instead of doing proper ATA initialization in 
>firmware ;-)
>
>Seriously, if you are a handed an ATA device that is actually in 
>operation when the kernel boots, you are already out of spec.

	1. Regardless of whatever specification you are referring to
or Andre's "31 second rule of [Power On Self Test]", it is genuinely
useful to boot faster by overlapping some other kernel work before the
drive is.  Specifications ultimately exist only to serve this
usefulness.  When a specification impedes usefulness, sometimes it's
the right decision to violate it.  Of course, we're not talking about
your IDE code violating such a specification, but rather not relying
on this particular guarantee.

	2. Besides, if this code is supposed to be a generic IDE core,
it many need to run on platforms that do not provide that guarantee or
where the boot code is not even capable of finding where all of the
IDE controllers.

	3. In the hierarchy of upgradability, it is generally easier
to replace the kernel than the Power On Self Test, which is more often
in flash or ROM, and which may require help from an unenthusiastic
hardware vendor.  So, it is better to weight trade-offs a few notches
in favor of avoid reliance on guarantees about the Power On Self Test.

	If I understand correctly, the cost of this trade off would be
adding one or two lines that add perhaps 20 bytes and as many CPU
cycles at initiailzation (except when this change really is necessary).

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

^ permalink raw reply	[flat|nested] 43+ messages in thread
* Re: IDE-flash device and hard disk on same controller
@ 2002-08-23  8:31 Adam J. Richter
  2002-08-23  8:59 ` Andre Hedrick
  2002-08-23  9:54 ` Andries Brouwer
  0 siblings, 2 replies; 43+ messages in thread
From: Adam J. Richter @ 2002-08-23  8:31 UTC (permalink / raw)
  To: andre; +Cc: ebiederm, jgarzik, linux-kernel

On Fri, 23 Aug 2002, Andre Hedrick wrote:
>On Thu, 22 Aug 2002, Adam J. Richter wrote:

>> 	1. Regardless of whatever specification you are referring to
>> or Andre's "31 second rule of [Power On Self Test]", it is genuinely
>> useful to boot faster by overlapping some other kernel work before the
>> drive is.  Specifications ultimately exist only to serve this
>> usefulness.  When a specification impedes usefulness, sometimes it's
>> the right decision to violate it.  Of course, we're not talking about

>Listen to yourself, and understand why 2.5 failed.

>"When a specification impedes usefulness, sometimes it's the right
>decision to violate it."

>"Gee there is no traffic in the on coming lanes, maybe I should use them."

>There are rules for how the hardware works, and if everything out there
>comes up in 4 seconds great.  If everything returns faster than the worst
>case great.  You start assuming everything behaves that way and you repeat
>history.

>You guys in 2.5 walked away from the rules because you thought you knew
>better, where did it get you?  Lost interrupts, PIO command block
>exectution failures, dropping EOT on PRD's because reading something into
>the published documents which is not there, etc ...


	Those are not examples of cases where the specification impedes
usefulness.  Those are examples where a specification helped usefulness
by helping compatability (not driving in oncoming lanes, not having timing
problems), and a decision made either out of recklessness (driving into
oncoming lanes) or, I infer, out of a misunderstanding of some document.

	However, your point is well taken in that when I said
"sometimes it's the right decision to violate [a specification]," I
did not mean by "sometimes" that this is a random event, like
"sometimes it rains."  I meant that it's a very careful decision, the
details of which differ from case to case, and that the result is not
always against.


>> your IDE code violating such a specification, but rather not relying
>> on this particular guarantee.
>> 
>> 	2. Besides, if this code is supposed to be a generic IDE core,
>> it many need to run on platforms that do not provide that guarantee or
>> where the boot code is not even capable of finding where all of the
>> IDE controllers.

>It is a means for probing signatures w/o identify to test for presence.
>It to has a 31 second rule.  Break the worst case and device get lost.

	Can you provide a reference for this "31 second rule?"  If
your reference does not directly discuss how it would impede the test
that you refer to, then you might want to explain that too.  Thanks in
advance.

>Please do not take this personal, because it is a technical arguemnet.

	Of couse, likewise.

>We do it by the books and then we cheat when we can, but only after we
>have all the proper stuff in place for compliance.

	Let's keep in perspective that I am talking adding a test that
would cause a delay until it is safe to proceed (unless you're saying
that waiting for the busy bit to clear is insufficient, in which case
I'd like to know how, but it would still be no more dangerous), and
you are advocating skipping that test.

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

	


^ permalink raw reply	[flat|nested] 43+ messages in thread
* Re: IDE-flash device and hard disk on same controller
@ 2002-08-23 10:14 Adam J. Richter
  0 siblings, 0 replies; 43+ messages in thread
From: Adam J. Richter @ 2002-08-23 10:14 UTC (permalink / raw)
  To: andre; +Cc: ebiederm, jgarzik, linux-kernel

Andre Hedrick wrote:
>Section 6.10

>EXECUTE DIAGNOSTICS:  Host Shall assert Reset (SRST) prior to issuing.

>Section 6.2 SoftReset (SRST)

>Device side State Diagram: D0SR3 "Set_Status_State"

>second paragraph

>"All actions required in this state shall be completed within 31 s"

>Page 86  Volume 3 ATA/ATAPI 7 rev 0, 5 November 2001.

>Sorry for the old reference it was the quickest hard copy I could find.


	Okay.  I found it on page 90  Volume 2 ATA/ATAPI 7 rev 0d,
8 July 2002 (http://www.t13.org/docs2002/d1532v2r0d.pdf).  Thanks for
the pointer.  I don't think I would have found it otherwise.

	As far as I can tell from looking at the state diagram, if the
BSY bit is clear, the DOSR3-->idle_S transition has occurred, as that
is the only transition in the entire diagram that clears the BSY bit.
The transition is labelled with BSY=0, and all other states are explicitly
labelled with BSY=1.  Likewise for the device 1 reset state diagram on
page 92 of the same document.

	There should also be no race before the busy bit is set
because "the device shall set BSY to one within 400ns after entering
this state [DOSR0: SRST]" (I think SRST means "software reset start"),
at least if we assume that it takes at least 400 *nanoseconds* to get
this far in the boot process.

	31 seconds seems to be the maximum amount of time that the drive
will take to reach the idle_S state, but it looks OK to poll BSY to see
if it has gotten there sooner.

	It looks to me like the scenario that Eric W. Biederman wanted
(the POST takes less than than 31 seconds and the IDE driver checks
BSY until it clears) is "in spec" with respect to those device 0 and
device 1 software reset state diagrams.

	Do you concur?  Do you see another problem?

	By the way, it might still be useful to have a timeout after
31 seconds, and fail the initialization if BSY is still set at that
point, so that the computer might be able to boot up far enough to
call for help if its a non-critical drive.

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

^ permalink raw reply	[flat|nested] 43+ messages in thread
* Re: IDE-flash device and hard disk on same controller
@ 2002-08-23 10:48 Adam J. Richter
  0 siblings, 0 replies; 43+ messages in thread
From: Adam J. Richter @ 2002-08-23 10:48 UTC (permalink / raw)
  To: aebr; +Cc: andre, ebiederm, jgarzik, linux-kernel

>Date: Fri, 23 Aug 2002 11:54:21 +0200
>From: Andries Brouwer <aebr@win.tue.nl>

>Read e.g. ATA-6.

> [If things work well, they may well be fast. But you are only entitled
> to conclude that something is wrong after waiting for 31 s. In
> particular, if you want to detect device 1 (the slave device), then
> only after 31 s you know that it is absent.]

We're only talking about going fast if we detect that things have gone well.


>See for example the Device power-on or hardware reset state diagram in 9.1.

	Thanks for the reference.  Pointing to the actual standards
makes these discussions a lot more efficient.

	What I said to Andre about software reset also apparently
applies to hardware reset.

	The state diagram that you refer to for hardware reset is on
page 312 of ATA/ATAPI-6 revision 3b, 28 February 2002 and
page 85 of ATA/ATAPI-7 revision 0d, 8 July 2002.  As with
software reset, BSY is asserted within 400ns of reset being asserted
and remains set until the transition at the end of the diagram
(D0HR3:Set_Status --> Device_idle_S).

	So, I think that Eric Biederman's suggestion about waiting for
BSY to clear, so as to accomodate Power On Self Test that can complete
in under 31 seconds should be OK.

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

^ permalink raw reply	[flat|nested] 43+ messages in thread
end of thread, other threads:[~2002-08-24 20:26 UTC | newest]

Thread overview: 43+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-08-19 18:31 IDE-flash device and hard disk on same controller Heater, Daniel (IndSys, GEFanuc, VMIC)
2002-08-19 19:21 ` Alan Cox
2002-08-20  8:44 ` Padraig Brady
  -- strict thread matches above, loose matches on Subject: below --
2002-08-20 19:52 Heater, Daniel (IndSys, GEFanuc, VMIC)
2002-08-20 21:57 ` Andre Hedrick
2002-08-20 22:00   ` Jeff Garzik
2002-08-20 22:28     ` Jeff Garzik
2002-08-21  6:36       ` Geert Uytterhoeven
2002-08-21  6:55         ` Andre Hedrick
2002-08-21  7:16           ` Geert Uytterhoeven
2002-08-22  5:34       ` Eric W. Biederman
2002-08-22 23:12         ` Jeff Garzik
2002-08-23  0:50           ` Eric W. Biederman
2002-08-23  1:26             ` Jeff Garzik
2002-08-23 11:03               ` Russell King
2002-08-23 11:41               ` Benjamin Herrenschmidt
2002-08-23 10:12                 ` Alan Cox
2002-08-23 13:09               ` Eric W. Biederman
2002-08-23  3:14             ` Andre Hedrick
2002-08-23 11:44               ` Benjamin Herrenschmidt
2002-08-24  2:02                 ` Jeff Garzik
2002-08-24  0:19                   ` Benjamin Herrenschmidt
2002-08-24  8:41                   ` Russell King
2002-08-24 20:28                     ` Andre Hedrick
2002-08-23  3:19             ` Andre Hedrick
2002-08-23  7:14               ` Helge Hafting
2002-08-23  7:49                 ` Andre Hedrick
2002-08-23 10:50               ` Geert Uytterhoeven
2002-08-23 11:08                 ` Russell King
2002-08-23 11:07               ` Russell King
2002-08-23 11:36           ` Benjamin Herrenschmidt
2002-08-22 13:41 ` bill davidsen
2002-08-21 13:22 Warner, Bill (IndSys, GEFanuc, VMIC)
2002-08-23  6:54 Adam J. Richter
2002-08-23  7:45 ` Andre Hedrick
2002-08-23 11:10   ` Russell King
2002-08-23 17:08     ` Andre Hedrick
2002-08-23 17:42       ` Andre Hedrick
2002-08-23  8:31 Adam J. Richter
2002-08-23  8:59 ` Andre Hedrick
2002-08-23  9:54 ` Andries Brouwer
2002-08-23 10:14 Adam J. Richter
2002-08-23 10:48 Adam J. Richter

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox