ADC Home > Reference Library > Technical Notes > Legacy Documents > Hardware & Drivers >
Important: This document is part of the Legacy section of the ADC Reference Library. This information should not be used for new development.
Current information on this Reference Library topic can be found here:
|
DockingDispatch trap supervisor mode bug and workaroundDate Written: 12/29/92 Last reviewed: 6/24/93 We're having a fatal problem using the DockingDispatch ($AA57) trap to get information about the Duo environment. When we call with a 'hdwr' selector, running virtual memory on a Duo 230 and a Duo Dock, we get a privilege violation on a
in some sort of patch (dock handler?) in the system heap. The 68030 isn't in supervisory mode. When we run without VM in the same setup, the 68030 is in supervisory mode and all is copacetic. When we try VM on a dockless Duo, or on a PowerBook 180 (with or without external video) the 'hdwr' selector works fine. Is there any documentation or guidance about which traps aren't safe to call because they require supervisory mode? ___ We recently discovered a bug in the configuration ROM on the Duo Dock. The bug is with a call to the _DockingDispatch trap using the hardware attribute selector when VM is on (only on the Duo Dock). The docking handler doesn't go into supervisor mode when running its hardware detection tests, and so when that call is made while running in user mode, the machine crashes, justifiably so, with a privilege error. The declaration ROM can't be patched at this point, so the only alternative is to surround the _DockingDispatch call with code to force entry into supervisor mode, as shown in the code fragment below.
Upon returning from _DockingDispatch, return to user mode is different because there's only a selector to _DebugUtil to go into supervisor mode--no selector to return or set user mode. That you'd have to do manually with the status register. Here's an example from some system code:
dockHardwareAttr dockHasVideo bitDate Written: 11/4/92 Last reviewed: 6/14/93 What are the implications of returning (or not returning) true for dockHasVideo in dockHardwareAttr? Is it sufficient to statically indicate that a bar supports a monitor? After all, the video driver can later determine whether a monitor is actually attached. Or is there an added benefit to reporting the presence of a monitor when DockingDispatch is called? ___ The dockHasVideo bit is used by the Docking Manager to determine whether or not it's reasonable to go to sleep. Sleeping is prevented under the following circumstances: the dockNoSleep bit is set in dockDockingAttr; the dockHasVideo bit is set in dockHardwareAttr; or the dockHasFPU bit is set in dockHardwareAttr. Apple's docking bars don't set the sleep bit in dockDockingAttr, but the two hardware bits are set. This way, sleep can work differently in the future without having to change the bars. The determination of whether a bar can go to sleep or not is made at docking initialization time. This occurs before slot PrimaryInits are run, so the video driver isn't yet up and running. If the hardware bit is set statically, that will indicate to the Docking Manager that video always exists, as in the case of the DuoDock. This will currently prevent the possibility of putting the system to sleep. Apple's MiniDock handles this situation by running through a very stripped down version of PrimaryInit with the sole purpose of determining whether or not a monitor is physically attached. dockingAttr dockingStation bitDate Written: 11/4/92 Last reviewed: 3/1/93 Does dockingStation true in DockingAttr imply enclosure (no LCD), AC power, SCC and modem port blocked, or what? ___ Our equates don't refer to dockingStation. Setting bit 3, dockNoLCDScreen, means that the internal LCD screen on the Duo shouldn't be used. Bit 4, dockEnclosingBar, means that the unit is physically enclosed by the bar, as in the case of the DuoDock. We're not aware of that information being used for anything specific. It implies the ports on the back are blocked, but that's a secondary implication. Certainly the MiniDock blocks the ports on the back as well, and it's not considered a docking station, so its dockEnclosingBar bit isn't set. dockSoundAttr dockHeadphoneAttached bitDate Written: 11/4/92 Last reviewed: 6/14/93 What are the implications of reporting dockHeadphoneAttached in dockSoundAttr? This seems superfluous because the presence of a headphone is directly detected at the main expansion connector, thus enabling or disabling power to sound portions of the bar via +5V SOUND. ___ Currently, there are no implications for either setting or clearing that bit. In the future, this may change, but neither DuoDock nor MiniDock set this bit, primarily for the reason you mention. Downloadables
|
|