lkml.org 
[lkml]   [2002]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] [RFC] Advanced TCA SCSI Disk Hotswap


Randy.Dunlap wrote:

>On Thu, 24 Oct 2002, Steven Dake wrote:
>
>| James
>| Some responses below:
>|
>| James Bottomley wrote:
>|
>| >sdake@mvista.com said:
>
>| >I don't really think it's the job of the kernel to conatin usage information.
>| >That's the job of the user level documentation.
>| >
>| >
>| I've gotten mixed feedback on this. I'll add you to the list that
>| doesn't like this.
>
>add me to that list also.
>
>| perhaps it should be removed (even though it takes up minimal memory).
>yes, i agree.
>
>| >>Imagine scanning each disk in driverfs looking at its WWN attribute
>| >>(if it has one) until a match is found. Assume there are 16 FC
>| >>devices. That is several hundred syscalls just to complete one
>| >>hotswap operation.
>| >>
>| >>
>| >
>| >Why is speed so important?
>| >
>| >
>| Telecoms and Datacoms have told me in numerous conversations that a hotswap
>| operation should occur in 20msec. I've arbitrarily set 10msec as my
>| target to
>| ensure that I meet the worse-case bus-is-loaded responses during scans, etc.
>|
>| I can't mention the names of the telecoms, but several with 10000+ employees
>| have mentioned it.
>
>| >>I think this would be too slow. 10 msec for my entire hotswap is
>| >>available. If you calculate 2msec for the actual hotswap disk
>| >>operation, that leaves 8 msec for the rest of the mess. Scanning
>| >>through tables or scanning tens or hundreds of files through hundreds
>| >>of syscalls may betoo slow.
>| >>
>| >
>| >Where does the 10ms figure come from?
>| >
>| See above
>
>I've already ask Steve about this and received his answers.
>Can't say that I agree with them though, so I asked someone from
>a Telecom Equipment Mfr. about this. He said that it's just for
>equipment testing, where technicians verify that hotswap works,
>and they are impatient to wait, so they practice surprise removal
>instead of coordinated removal. He doesn't think that's how it's
>actually done out in the field, just in test labs.
>
>Preface question: does cPCI support surprise removal (in the
>PICMG specs, not in some implementation)? I know that PCI hotplug
>doesn't support surprise removal, only "coordinated" removal.
>
>
PICMG 2.12 doesn't support surprise removal (the hardware does, the
software doesn't).
The latch must first be popped, then the user must wait for the blue
led. If the blue led
isn't lit, the operating system isn't ready for the board to be removed.

This said, operators are paid 10 bucks an hour to replace boards and you
know how that goes. :)

For Compact PCI, the surprise removal rate is about 100 msec. This is
as fast as the user can
rip the board out of a chassis, meaning if you can light the blue led in
less then 100 msec
it doesn't matter if the extraction is a surprise or not.

>So the question that has to be answered IMO is: do we want to
>support surprise removal for something like manufacturing test,
>which doesn't abide by the coordinated removal protocol?
>
>or: Do we have to support surprise removal, only because it can't
>be prevented? I expect that this is the case, but I still don't
>see or understand the 20 ms time requirement.
>
>
For Advanced TCA, there isn't a "latch" required to unpop before
removing the board. For
Compact PCI, the latch must be popped, allowing a signal to be sent to
the board. For ATCA,
a button is pressed (which is a major complaint of Advanced TCA, boards
can be removed without
any signaling to the OS that the board is being removed). I'm not sure
what the PICMG3 foks
are going to do about that problem. I'm assuming they are going to
rework the enumeration of
the hotswap event to be driven by extracting the board instead of by a
button.

In this case, extremely fast hotswap times are required, because the
board can be removed
very fast in Advanced TCA (vs the latched method of Compact PCI).

Perhaps this is where the timing constraints originate.

>
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:30    [from the cache]
©2003-2011 Jasper Spaans