Can you try with this patch? From what I can see of Apple ACPI tables,
it should be functionally equivalent but less hate inducing.
commit 9c8c25fda1b993a81b1a3a9bc4e9e8b0d7ac4062
Author: Matthew Garrett <[email protected]>
Date: Tue Jun 1 14:40:55 2010 -0400
x86: Default to using ACPI for reboot
Running a hacked qemu with a modified seabios image that declares support
for reboot via ACPI shows that Windows will use the ACPI reboot vector
before falling back to hitting i8042. Change the default reboot method to
match this. This looks like it should improve life for Apples, which
declare the cf9 reboot method via ACPI, don't have a competent i8042
emulation and currently have a large DMI whitelist.
Signed-off-by: Matthew Garrett <[email protected]>
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 8e1aac8..0a04c4b 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -34,7 +34,7 @@ EXPORT_SYMBOL(pm_power_off);
static const struct desc_ptr no_idt = {};
static int reboot_mode;
-enum reboot_type reboot_type = BOOT_KBD;
+enum reboot_type reboot_type = BOOT_ACPI;
int reboot_force;
#if defined(CONFIG_X86_32) && defined(CONFIG_SMP)
--
Matthew Garrett | [email protected]
On 06/01/2010 12:00 PM, Matthew Garrett wrote:
> Can you try with this patch? From what I can see of Apple ACPI tables,
> it should be functionally equivalent but less hate inducing.
>
> commit 9c8c25fda1b993a81b1a3a9bc4e9e8b0d7ac4062
> Author: Matthew Garrett<[email protected]>
> Date: Tue Jun 1 14:40:55 2010 -0400
>
> x86: Default to using ACPI for reboot
>
> Running a hacked qemu with a modified seabios image that declares support
> for reboot via ACPI shows that Windows will use the ACPI reboot vector
> before falling back to hitting i8042. Change the default reboot method to
> match this. This looks like it should improve life for Apples, which
> declare the cf9 reboot method via ACPI, don't have a competent i8042
> emulation and currently have a large DMI whitelist.
>
> Signed-off-by: Matthew Garrett<[email protected]>
>
> diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
> index 8e1aac8..0a04c4b 100644
> --- a/arch/x86/kernel/reboot.c
> +++ b/arch/x86/kernel/reboot.c
> @@ -34,7 +34,7 @@ EXPORT_SYMBOL(pm_power_off);
>
> static const struct desc_ptr no_idt = {};
> static int reboot_mode;
> -enum reboot_type reboot_type = BOOT_KBD;
> +enum reboot_type reboot_type = BOOT_ACPI;
> int reboot_force;
>
> #if defined(CONFIG_X86_32)&& defined(CONFIG_SMP)
>
o.k. applied.. unfortunately
I get init telling me it's rebooting,
then, nothing but a black screen.
Justin P. Mattock
On Tue, Jun 01, 2010 at 12:14:07PM -0700, Justin P. Mattock wrote:
> o.k. applied.. unfortunately
> I get init telling me it's rebooting,
> then, nothing but a black screen.
Could you send me the output of acpidump on this machine? Also, try
building the following app and running it as root:
#include <sys/io.h>
int main() {
outb(6, 0xcf9);
return 0;
}
and see if the machine reboots.
--
Matthew Garrett | [email protected]
On 06/01/2010 12:21 PM, Matthew Garrett wrote:
> On Tue, Jun 01, 2010 at 12:14:07PM -0700, Justin P. Mattock wrote:
>
>> o.k. applied.. unfortunately
>> I get init telling me it's rebooting,
>> then, nothing but a black screen.
>
> Could you send me the output of acpidump on this machine? Also, try
> building the following app and running it as root:
>
> #include<sys/io.h>
>
> int main() {
> outb(6, 0xcf9);
> return 0;
> }
>
> and see if the machine reboots.
>
nope.. here is what I get:
./reboot
Segmentation fault (core dumped)
and in dmesg:
[ 1401.323601] reboot[3615] general protection ip:40048b
sp:7fff2a601910 error:0 in reboot[400000+1000]
Justin P. Mattock
On Tue, Jun 01, 2010 at 01:06:17PM -0700, Justin P. Mattock wrote:
> nope.. here is what I get:
> ./reboot
> Segmentation fault (core dumped)
Sorry, put
iopl(3);
before the outb.
--
Matthew Garrett | [email protected]
On 06/01/2010 01:07 PM, Matthew Garrett wrote:
> On Tue, Jun 01, 2010 at 01:06:17PM -0700, Justin P. Mattock wrote:
>
>> nope.. here is what I get:
>> ./reboot
>> Segmentation fault (core dumped)
>
> Sorry, put
>
> iopl(3);
>
> before the outb.
>
still craps out.
this is what the code looks like now:
#include <sys/io.h>
int main() {
iopl(3);
outb(6, 0xcf9);
return 0;
}
(hopefully done right).
as for the acpidump, I seem
to be hitting some error trying
to dissemble it, so I just grabbed my copy from:
https://bugzilla.kernel.org/show_bug.cgi?id=14483
what/where might I be looking for, for this reboot
port in the *.dsl?
Justin P. Mattock
On Tue, Jun 01, 2010 at 01:17:42PM -0700, Justin P. Mattock wrote:
> still craps out.
> this is what the code looks like now:
You're running it as root, right? It behaves exactly as I'd expect here.
--
Matthew Garrett | [email protected]
On 06/01/2010 01:21 PM, Matthew Garrett wrote:
> On Tue, Jun 01, 2010 at 01:17:42PM -0700, Justin P. Mattock wrote:
>
>> still craps out.
>> this is what the code looks like now:
>
> You're running it as root, right? It behaves exactly as I'd expect here.
>
the first run of this was normally.
then root..
(and your right this time after the
change I forgot to do a su)
now running as root gives nothing.
Justin P. Mattock
On Tue, Jun 01, 2010 at 01:31:08PM -0700, Justin P. Mattock wrote:
> now running as root gives nothing.
It returns you to the prompt? The machine hangs? What do you mean by
"nothing"? (Also, what chipset does this machine have?)
--
Matthew Garrett | [email protected]
On 06/01/2010 01:33 PM, Matthew Garrett wrote:
> On Tue, Jun 01, 2010 at 01:31:08PM -0700, Justin P. Mattock wrote:
>
>> now running as root gives nothing.
>
> It returns you to the prompt? The machine hangs? What do you mean by
> "nothing"? (Also, what chipset does this machine have?)
>
this is what it does:
It returns you to the prompt
as for the chipset name..(not sure)
intel with nvidia(right after santa rosa was
released(I don't keep track of chipsets)..
iMac9,1
Justin P. Mattock
On Tue, Jun 01, 2010 at 01:51:00PM -0700, Justin P. Mattock wrote:
> On 06/01/2010 01:33 PM, Matthew Garrett wrote:
>> On Tue, Jun 01, 2010 at 01:31:08PM -0700, Justin P. Mattock wrote:
>> It returns you to the prompt? The machine hangs? What do you mean by
>> "nothing"? (Also, what chipset does this machine have?)
>>
>
> this is what it does:
> It returns you to the prompt
Ok, so it does nothing. Sigh. Thapple.
> as for the chipset name..(not sure)
It's an MCP79. In that case I suspect that we're misdiagnosing this at
some level. How about the following (again, run as root):
#include <sys/io.h>
int main() {
iopl(3);
outb(0xfe, 0x64);
return 0;
}
--
Matthew Garrett | [email protected]
On 06/01/2010 02:12 PM, Matthew Garrett wrote:
> On Tue, Jun 01, 2010 at 01:51:00PM -0700, Justin P. Mattock wrote:
>> On 06/01/2010 01:33 PM, Matthew Garrett wrote:
>>> On Tue, Jun 01, 2010 at 01:31:08PM -0700, Justin P. Mattock wrote:
>>> It returns you to the prompt? The machine hangs? What do you mean by
>>> "nothing"? (Also, what chipset does this machine have?)
>>>
>>
>> this is what it does:
>> It returns you to the prompt
>
> Ok, so it does nothing. Sigh. Thapple.
>
responds the same way..
>> as for the chipset name..(not sure)
>
> It's an MCP79. In that case I suspect that we're misdiagnosing this at
alright.. yeah it's MCP79
> some level. How about the following (again, run as root):
>
> #include<sys/io.h>
>
> int main() {
> iopl(3);
> outb(0xfe, 0x64);
> return 0;
> }
>
ahh!! I see now:
grep 0x64 *.dsl
Sleep (0x64)
Sleep (0x64)
Sleep (0x64)
OperationRegion (P64, PCI_Config, 0x64, 0x02)
Name (M73L, 0x64)
Divide (Local1, 0x64, , Local0)
Sleep (0x64)
Justin P. Mattock
On Tue, Jun 01, 2010 at 02:26:01PM -0700, Justin P. Mattock wrote:
> On 06/01/2010 02:12 PM, Matthew Garrett wrote:
>> some level. How about the following (again, run as root):
>>
>> #include<sys/io.h>
>>
>> int main() {
>> iopl(3);
>> outb(0xfe, 0x64);
>> return 0;
>> }
>>
So, just to be clear, you run this as root and it immediately returns
you to the prompt? This seems unlikely.
> ahh!! I see now:
> grep 0x64 *.dsl
No, that's unrelated.
--
Matthew Garrett | [email protected]
On 06/01/2010 02:29 PM, Matthew Garrett wrote:
> On Tue, Jun 01, 2010 at 02:26:01PM -0700, Justin P. Mattock wrote:
>> On 06/01/2010 02:12 PM, Matthew Garrett wrote:
>>> some level. How about the following (again, run as root):
>>>
>>> #include<sys/io.h>
>>>
>>> int main() {
>>> iopl(3);
>>> outb(0xfe, 0x64);
>>> return 0;
>>> }
>>>
>
> So, just to be clear, you run this as root and it immediately returns
> you to the prompt? This seems unlikely.
yep.. with the above code
I (save to a file) then
non-root gcc reboot.c -o reboot
then su
./reboot
just bake to the command prompt
>
>> ahh!! I see now:
>> grep 0x64 *.dsl
>
> No, that's unrelated.
>
alright!!
Justin P. Mattock
On Tue, Jun 01, 2010 at 02:43:12PM -0700, Justin P. Mattock wrote:
> On 06/01/2010 02:29 PM, Matthew Garrett wrote:
>> So, just to be clear, you run this as root and it immediately returns
>> you to the prompt? This seems unlikely.
>
> yep.. with the above code
> I (save to a file) then
> non-root gcc reboot.c -o reboot
> then su
> ./reboot
> just bake to the command prompt
Are you running some sort of security policy that might block hardware
access? I'm going to have to find one of these machines to test with -
on everything I have here, the cf9 write and the keyboard controller
write both generate reboots. The worst case should be a hung machine,
not one that continues running...
--
Matthew Garrett | [email protected]
On 06/01/2010 02:48 PM, Matthew Garrett wrote:
> On Tue, Jun 01, 2010 at 02:43:12PM -0700, Justin P. Mattock wrote:
>> On 06/01/2010 02:29 PM, Matthew Garrett wrote:
>>> So, just to be clear, you run this as root and it immediately returns
>>> you to the prompt? This seems unlikely.
>>
>> yep.. with the above code
>> I (save to a file) then
>> non-root gcc reboot.c -o reboot
>> then su
>> ./reboot
>> just bake to the command prompt
>
> Are you running some sort of security policy that might block hardware
> access? I'm going to have to find one of these machines to test with -
> on everything I have here, the cf9 write and the keyboard controller
> write both generate reboots. The worst case should be a hung machine,
> not one that continues running...
>
yeah I just checked
/usr/sbin/sestatus has everything in permissive
mode. as for the system it's fedora 13
as for testing on this machine
if your in Ventura county let me know
Justin P. Mattock
On 06/01/2010 03:43 PM, Justin P. Mattock wrote:
> On 06/01/2010 02:29 PM, Matthew Garrett wrote:
>> On Tue, Jun 01, 2010 at 02:26:01PM -0700, Justin P. Mattock wrote:
>>> On 06/01/2010 02:12 PM, Matthew Garrett wrote:
>>>> some level. How about the following (again, run as root):
>>>>
>>>> #include<sys/io.h>
>>>>
>>>> int main() {
>>>> iopl(3);
>>>> outb(0xfe, 0x64);
>>>> return 0;
>>>> }
>>>>
>>
>> So, just to be clear, you run this as root and it immediately returns
>> you to the prompt? This seems unlikely.
>
> yep.. with the above code
> I (save to a file) then
> non-root gcc reboot.c -o reboot
> then su
> ./reboot
> just bake to the command prompt
Can you post the FACP section of the acpidump output from this machine?
>
>>
>>> ahh!! I see now:
>>> grep 0x64 *.dsl
>>
>> No, that's unrelated.
>>
>
> alright!!
>
> Justin P. Mattock
On 06/01/2010 10:11 PM, Robert Hancock wrote:
> On 06/01/2010 03:43 PM, Justin P. Mattock wrote:
>> On 06/01/2010 02:29 PM, Matthew Garrett wrote:
>>> On Tue, Jun 01, 2010 at 02:26:01PM -0700, Justin P. Mattock wrote:
>>>> On 06/01/2010 02:12 PM, Matthew Garrett wrote:
>>>>> some level. How about the following (again, run as root):
>>>>>
>>>>> #include<sys/io.h>
>>>>>
>>>>> int main() {
>>>>> iopl(3);
>>>>> outb(0xfe, 0x64);
>>>>> return 0;
>>>>> }
>>>>>
>>>
>>> So, just to be clear, you run this as root and it immediately returns
>>> you to the prompt? This seems unlikely.
>>
>> yep.. with the above code
>> I (save to a file) then
>> non-root gcc reboot.c -o reboot
>> then su
>> ./reboot
>> just bake to the command prompt
>
> Can you post the FACP section of the acpidump output from this machine?
>
here you go:
/*
* Intel ACPI Component Architecture
* AML Disassembler version 20090123
*
* Disassembly of FACP.dat, Tue Jun 1 22:58:36 2010
*
* ACPI Data Table [FACP]
*
* Format: [HexOffset DecimalOffset ByteLength] FieldName : FieldValue
*/
[000h 000 4] Signature : "FACP" /* Fixed ACPI
Description Table */
[004h 004 4] Table Length : 000000F4
[008h 008 1] Revision : 03
[009h 009 1] Checksum : 0B
[00Ah 010 6] Oem ID : "APPLE "
[010h 016 8] Oem Table ID : "Apple00 "
[018h 024 4] Oem Revision : 0000008D
[01Ch 028 4] Asl Compiler ID : "Loki"
[020h 032 4] Asl Compiler Revision : 0000005F
[024h 036 4] FACS Address : BFECD000
[028h 040 4] DSDT Address : BFEE0000
[02Ch 044 1] Model : 00
[02Dh 045 1] PM Profile : 01
[02Eh 046 2] SCI Interrupt : 0009
[030h 048 4] SMI Command Port : 0000052E
[034h 052 1] ACPI Enable Value : F0
[035h 053 1] ACPI Disable Value : F1
[036h 054 1] S4BIOS Command : F2
[037h 055 1] P-State Control : 80
[038h 056 4] PM1A Event Block Address : 00000400
[03Ch 060 4] PM1B Event Block Address : 00000000
[040h 064 4] PM1A Control Block Address : 00000404
[044h 068 4] PM1B Control Block Address : 00000000
[048h 072 4] PM2 Control Block Address : 0000041C
[04Ch 076 4] PM Timer Block Address : 00000408
[050h 080 4] GPE0 Block Address : 00000420
[054h 084 4] GPE1 Block Address : 000005A0
[058h 088 1] PM1 Event Block Length : 04
[059h 089 1] PM1 Control Block Length : 02
[05Ah 090 1] PM2 Control Block Length : 01
[05Bh 091 1] PM Timer Block Length : 04
[05Ch 092 1] GPE0 Block Length : 08
[05Dh 093 1] GPE1 Block Length : 10
[05Eh 094 1] GPE1 Base Offset : 20
[05Fh 095 1] _CST Support : 00
[060h 096 2] C2 Latency : 0065
[062h 098 2] C3 Latency : 03E9
[064h 100 2] CPU Cache Size : 0000
[066h 102 2] Cache Flush Stride : 0000
[068h 104 1] Duty Cycle Offset : 01
[069h 105 1] Duty Cycle Width : 03
[06Ah 106 1] RTC Day Alarm Index : 7D
[06Bh 107 1] RTC Month Alarm Index : 7E
[06Ch 108 1] RTC Century Index : 32
[06Dh 109 2] Boot Flags (decoded below) : 0001
Legacy Devices Supported (V2) : 1
8042 Present on ports 60/64 (V2) : 0
VGA Not Present (V4) : 0
MSI Not Supported (V4) : 0
PCIe ASPM Not Supported (V4) : 0
[06Fh 111 1] Reserved : 00
[070h 112 4] Flags (decoded below) : 00008425
WBINVD instruction is operational (V1) : 1
WBINVD flushes all caches (V1) : 0
All CPUs support C1 (V1) : 1
C2 works on MP system (V1) : 0
Control Method Power Button (V1) : 0
Control Method Sleep Button (V1) : 1
RTC wakeup reg not in fixed space (V1) : 0
RTC can wake system from S4 (V1) : 0
32-bit PM Timer (V1) : 0
Docking Supported (V1) : 0
Reset Register Supported (V2) : 1
Sealed Case (V3) : 0
Headless - No Video (V3) : 0
Use native instr after SLP_TYPx (V3) : 0
PCIEXP_WAK Bits Supported (V4) : 0
Use Platform Timer (V4) : 1
RTC_STS valid on S4 wake (V4) : 0
Remote Power-on capable (V4) : 0
Use APIC Cluster Model (V4) : 0
Use APIC Physical Destination Mode (V4) : 0
[074h 116 12] Reset Register : <Generic Address Structure>
[074h 116 1] Space ID : 01 (SystemIO)
[075h 117 1] Bit Width : 08
[076h 118 1] Bit Offset : 00
[077h 119 1] Access Width : 00
[078h 120 8] Address : 0000000000000CF9
[080h 128 1] Value to cause reset : 06
[081h 129 3] Reserved : 000000
[084h 132 8] FACS Address : 00000000BFECD000
[08Ch 140 8] DSDT Address : 00000000BFEE0000
[094h 148 12] PM1A Event Block : <Generic Address Structure>
[094h 148 1] Space ID : 01 (SystemIO)
[095h 149 1] Bit Width : 20
[096h 150 1] Bit Offset : 00
[097h 151 1] Access Width : 00
[098h 152 8] Address : 0000000000000400
[0A0h 160 12] PM1B Event Block : <Generic Address Structure>
[0A0h 160 1] Space ID : 01 (SystemIO)
[0A1h 161 1] Bit Width : 00
[0A2h 162 1] Bit Offset : 00
[0A3h 163 1] Access Width : 00
[0A4h 164 8] Address : 0000000000000000
[0ACh 172 12] PM1A Control Block : <Generic Address Structure>
[0ACh 172 1] Space ID : 01 (SystemIO)
[0ADh 173 1] Bit Width : 10
[0AEh 174 1] Bit Offset : 00
[0AFh 175 1] Access Width : 00
[0B0h 176 8] Address : 0000000000000404
[0B8h 184 12] PM1B Control Block : <Generic Address Structure>
[0B8h 184 1] Space ID : 01 (SystemIO)
[0B9h 185 1] Bit Width : 00
[0BAh 186 1] Bit Offset : 00
[0BBh 187 1] Access Width : 00
[0BCh 188 8] Address : 0000000000000000
[0C4h 196 12] PM2 Control Block : <Generic Address Structure>
[0C4h 196 1] Space ID : 01 (SystemIO)
[0C5h 197 1] Bit Width : 08
[0C6h 198 1] Bit Offset : 00
[0C7h 199 1] Access Width : 00
[0C8h 200 8] Address : 000000000000041C
[0D0h 208 12] PM Timer Block : <Generic Address Structure>
[0D0h 208 1] Space ID : 01 (SystemIO)
[0D1h 209 1] Bit Width : 20
[0D2h 210 1] Bit Offset : 00
[0D3h 211 1] Access Width : 00
[0D4h 212 8] Address : 0000000000000408
[0DCh 220 12] GPE0 Block : <Generic Address Structure>
[0DCh 220 1] Space ID : 01 (SystemIO)
[0DDh 221 1] Bit Width : 40
[0DEh 222 1] Bit Offset : 00
[0DFh 223 1] Access Width : 00
[0E0h 224 8] Address : 0000000000000420
[0E8h 232 12] GPE1 Block : <Generic Address Structure>
[0E8h 232 1] Space ID : 01 (SystemIO)
[0E9h 233 1] Bit Width : 80
[0EAh 234 1] Bit Offset : 00
[0EBh 235 1] Access Width : 00
[0ECh 236 8] Address : 00000000000005A0
Raw Table Data
0000: 46 41 43 50 F4 00 00 00 03 0B 41 50 50 4C 45 20 FACP......APPLE
0010: 41 70 70 6C 65 30 30 20 8D 00 00 00 4C 6F 6B 69 Apple00 ....Loki
0020: 5F 00 00 00 00 D0 EC BF 00 00 EE BF 00 01 09 00 _...............
0030: 2E 05 00 00 F0 F1 F2 80 00 04 00 00 00 00 00 00 ................
0040: 04 04 00 00 00 00 00 00 1C 04 00 00 08 04 00 00 ................
0050: 20 04 00 00 A0 05 00 00 04 02 01 04 08 10 20 00 ............. .
0060: 65 00 E9 03 00 00 00 00 01 03 7D 7E 32 01 00 00 e.........}~2...
0070: 25 84 00 00 01 08 00 00 F9 0C 00 00 00 00 00 00 %...............
0080: 06 00 00 00 00 D0 EC BF 00 00 00 00 00 00 EE BF ................
0090: 00 00 00 00 01 20 00 00 00 04 00 00 00 00 00 00 ..... ..........
00A0: 01 00 00 00 00 00 00 00 00 00 00 00 01 10 00 00 ................
00B0: 04 04 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................
00C0: 00 00 00 00 01 08 00 00 1C 04 00 00 00 00 00 00 ................
00D0: 01 20 00 00 08 04 00 00 00 00 00 00 01 40 00 00 . ...........@..
00E0: 20 04 00 00 00 00 00 00 01 80 00 00 A0 05 00 00 ...............
00F0: 00 00 00 00 ....
hopefully the table didnt get garbled by the mail client.
Justin P. Mattock
On Tue, 1 Jun 2010 22:48:20 +0100
Matthew Garrett <[email protected]> wrote:
> On Tue, Jun 01, 2010 at 02:43:12PM -0700, Justin P. Mattock wrote:
> > On 06/01/2010 02:29 PM, Matthew Garrett wrote:
> >> So, just to be clear, you run this as root and it immediately returns
> >> you to the prompt? This seems unlikely.
> >
> > yep.. with the above code
> > I (save to a file) then
> > non-root gcc reboot.c -o reboot
> > then su
> > ./reboot
> > just bake to the command prompt
>
> Are you running some sort of security policy that might block hardware
> access?
Try
if (iopl(...))
perror
... (or strace it running as root)
On 06/02/2010 05:08 AM, Alan Cox wrote:
> On Tue, 1 Jun 2010 22:48:20 +0100
> Matthew Garrett<[email protected]> wrote:
>
>> On Tue, Jun 01, 2010 at 02:43:12PM -0700, Justin P. Mattock wrote:
>>> On 06/01/2010 02:29 PM, Matthew Garrett wrote:
>>>> So, just to be clear, you run this as root and it immediately returns
>>>> you to the prompt? This seems unlikely.
>>>
>>> yep.. with the above code
>>> I (save to a file) then
>>> non-root gcc reboot.c -o reboot
>>> then su
>>> ./reboot
>>> just bake to the command prompt
>>
>> Are you running some sort of security policy that might block hardware
>> access?
>
> Try
>
> if (iopl(...))
> perror
>
> ... (or strace it running as root)
>
o.k. here's the code with perror, and strace:
#include <sys/io.h>
#include <stdio.h>
int main() {
iopl(3);
outb(0xfe, 0x64);
perror("something broke");
}
output in terminal:
something broke: Success
strace:
execve("./reboot", ["./reboot"], [/* 42 vars */]) = 0
brk(0) = 0x601000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f0f50247000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=80596, ...}) = 0
mmap(NULL, 80596, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f0f50233000
close(3) = 0
open("/lib64/libc.so.6", O_RDONLY) = 3
read(3,
"\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\355\241.;\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1838360, ...}) = 0
mmap(0x3b2ea00000, 3664040, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x3b2ea00000
mprotect(0x3b2eb75000, 2097152, PROT_NONE) = 0
mmap(0x3b2ed75000, 20480, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x175000) = 0x3b2ed75000
mmap(0x3b2ed7a000, 18600, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x3b2ed7a000
close(3) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f0f50232000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f0f50231000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f0f50230000
arch_prctl(ARCH_SET_FS, 0x7f0f50231700) = 0
mprotect(0x3b2ed75000, 16384, PROT_READ) = 0
mprotect(0x3b2e61e000, 4096, PROT_READ) = 0
munmap(0x7f0f50233000, 80596) = 0
iopl(0x3) = 0
dup(2) = 3
fcntl(3, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE)
brk(0) = 0x601000
brk(0x622000) = 0x622000
fstat(3, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f0f50246000
lseek(3, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
write(3, "something broke: Success\n", 25something broke: Success
) = 25
close(3) = 0
munmap(0x7f0f50246000, 4096) = 0
exit_group(0) = ?
what/where does one look for this keycode
if I may say?
Justin P. Mattock
On Wed, Jun 2, 2010 at 12:01 AM, Justin P. Mattock
<[email protected]> wrote:
>> Can you post the FACP section of the acpidump output from this machine?
>>
>
> here you go:
>
> ? ? ? ? ? ? Reset Register Supported (V2) : 1
> [074h 116 12] ? ? ? ? ? ? ? Reset Register : <Generic Address Structure>
> [074h 116 ?1] ? ? ? ? ? ? ? ? ? ? Space ID : 01 (SystemIO)
> [075h 117 ?1] ? ? ? ? ? ? ? ? ? ?Bit Width : 08
> [076h 118 ?1] ? ? ? ? ? ? ? ? ? Bit Offset : 00
> [077h 119 ?1] ? ? ? ? ? ? ? ? Access Width : 00
> [078h 120 ?8] ? ? ? ? ? ? ? ? ? ? ?Address : 0000000000000CF9
>
> [080h 128 ?1] ? ? ? ? Value to cause reset : 06
Hmm, so the FADT says the reset register is listed as supported, and
says writing 0x06 to 0xCF9 is supposed to do it.. That's exactly what
this should do:
#include <sys/io.h>
int main() {
iopl(3);
outb(6, 0xcf9);
return 0;
}
but you said that didn't do anything.. It kind of seems like ACPI
reboot is busted on this machine then, but then I wonder how Windows
manages to work..
On 06/02/2010 04:18 PM, Robert Hancock wrote:
> On Wed, Jun 2, 2010 at 12:01 AM, Justin P. Mattock
> <[email protected]> wrote:
>>> Can you post the FACP section of the acpidump output from this machine?
>>>
>>
>> here you go:
>>
>
>
>> Reset Register Supported (V2) : 1
>
>> [074h 116 12] Reset Register :<Generic Address Structure>
>> [074h 116 1] Space ID : 01 (SystemIO)
>> [075h 117 1] Bit Width : 08
>> [076h 118 1] Bit Offset : 00
>> [077h 119 1] Access Width : 00
>> [078h 120 8] Address : 0000000000000CF9
>>
>> [080h 128 1] Value to cause reset : 06
>
> Hmm, so the FADT says the reset register is listed as supported, and
> says writing 0x06 to 0xCF9 is supposed to do it.. That's exactly what
> this should do:
>
> #include<sys/io.h>
>
> int main() {
> iopl(3);
> outb(6, 0xcf9);
> return 0;
> }
>
> but you said that didn't do anything.. It kind of seems like ACPI
> reboot is busted on this machine then, but then I wonder how Windows
> manages to work..
>
alright!! I have a better idea at what this is now..
as for the above code, yes this one segfaults,
the other code posted on the thread just returns
a command prompt(testing:
#include <sys/io.h>
int main() {
iopl(3);
outb(0xfe, 0xcf9);
return 0;
}
on a dell reboot's as is.)
both my macbook, and imac are
broken with the above.(but for whatever
reason the macbook doesnt need an dmi entry
in reboot.c just iMac9,1 etc..)
so the address for the CF9 is this:
[074h 116 12] Reset Register : <Generic Address Structure>
[074h 116 1] Space ID : 01 (SystemIO)
[075h 117 1] Bit Width : 08
[076h 118 1] Bit Offset : 00
[077h 119 1] Access Width : 00
[078h 120 8] Address : 0000000000000CF9
[080h 128 1] Value to cause reset : 06
[081h 129 3] Reserved : 000000
[084h 132 8] FACS Address : 00000000BFECD000
[08Ch 140 8] DSDT Address : 00000000BFEE0000
[094h 148 12] PM1A Event Block : <Generic Address Structure>
[094h 148 1] Space ID : 01 (SystemIO)
[095h 149 1] Bit Width : 20
[096h 150 1] Bit Offset : 00
[097h 151 1] Access Width : 00
[098h 152 8] Address : 0000000000000400
not sure how to read this, but are there
two devices here i.g.
is the top a cold boot(reset register) and
the bottom(value to cause reset) a warm boot?
at the moment I'm trying to figure out what/where
*((unsigned short *)__va(0x472)) = reboot_mode;
0x472 comes from as well as 0x1234 then
#define KBD_STATUS_REG 0x64
to see if I can see anything.
thanks for the info on this..
Justin P. Mattock
On 06/02/2010 05:43 PM, Justin P. Mattock wrote:
> On 06/02/2010 04:18 PM, Robert Hancock wrote:
>> On Wed, Jun 2, 2010 at 12:01 AM, Justin P. Mattock
>> <[email protected]> wrote:
>>>> Can you post the FACP section of the acpidump output from this machine?
>>>>
>>>
>>> here you go:
>>>
>>
>>
>>> Reset Register Supported (V2) : 1
>>
>>> [074h 116 12] Reset Register :<Generic Address Structure>
>>> [074h 116 1] Space ID : 01 (SystemIO)
>>> [075h 117 1] Bit Width : 08
>>> [076h 118 1] Bit Offset : 00
>>> [077h 119 1] Access Width : 00
>>> [078h 120 8] Address : 0000000000000CF9
>>>
>>> [080h 128 1] Value to cause reset : 06
>>
>> Hmm, so the FADT says the reset register is listed as supported, and
>> says writing 0x06 to 0xCF9 is supposed to do it.. That's exactly what
>> this should do:
>>
>> #include<sys/io.h>
>>
>> int main() {
>> iopl(3);
>> outb(6, 0xcf9);
>> return 0;
>> }
>>
>> but you said that didn't do anything.. It kind of seems like ACPI
>> reboot is busted on this machine then, but then I wonder how Windows
>> manages to work..
>>
>
>
> alright!! I have a better idea at what this is now..
> as for the above code, yes this one segfaults,
> the other code posted on the thread just returns
> a command prompt(testing:
You get a segfault on that one? Running as root?
>
> #include <sys/io.h>
>
> int main() {
> iopl(3);
> outb(0xfe, 0xcf9);
> return 0;
> }
> on a dell reboot's as is.)
>
> both my macbook, and imac are
> broken with the above.(but for whatever
> reason the macbook doesnt need an dmi entry
> in reboot.c just iMac9,1 etc..)
>
> so the address for the CF9 is this:
>
> [074h 116 12] Reset Register : <Generic Address Structure>
> [074h 116 1] Space ID : 01 (SystemIO)
> [075h 117 1] Bit Width : 08
> [076h 118 1] Bit Offset : 00
> [077h 119 1] Access Width : 00
> [078h 120 8] Address : 0000000000000CF9
>
> [080h 128 1] Value to cause reset : 06
> [081h 129 3] Reserved : 000000
> [084h 132 8] FACS Address : 00000000BFECD000
> [08Ch 140 8] DSDT Address : 00000000BFEE0000
> [094h 148 12] PM1A Event Block : <Generic Address Structure>
> [094h 148 1] Space ID : 01 (SystemIO)
> [095h 149 1] Bit Width : 20
> [096h 150 1] Bit Offset : 00
> [097h 151 1] Access Width : 00
> [098h 152 8] Address : 0000000000000400
>
> not sure how to read this, but are there
> two devices here i.g.
> is the top a cold boot(reset register) and
> the bottom(value to cause reset) a warm boot?
No, the stuff after "Value to cause reset" is something else entirely.
>
> at the moment I'm trying to figure out what/where
> *((unsigned short *)__va(0x472)) = reboot_mode;
> 0x472 comes from as well as 0x1234 then
> #define KBD_STATUS_REG 0x64
> to see if I can see anything.
>
>
> thanks for the info on this..
>
> Justin P. Mattock
>
On 06/02/2010 04:45 PM, Robert Hancock wrote:
> On 06/02/2010 05:43 PM, Justin P. Mattock wrote:
>> On 06/02/2010 04:18 PM, Robert Hancock wrote:
>>> On Wed, Jun 2, 2010 at 12:01 AM, Justin P. Mattock
>>> <[email protected]> wrote:
>>>>> Can you post the FACP section of the acpidump output from this
>>>>> machine?
>>>>>
>>>>
>>>> here you go:
>>>>
>>>
>>>
>>>> Reset Register Supported (V2) : 1
>>>
>>>> [074h 116 12] Reset Register :<Generic Address Structure>
>>>> [074h 116 1] Space ID : 01 (SystemIO)
>>>> [075h 117 1] Bit Width : 08
>>>> [076h 118 1] Bit Offset : 00
>>>> [077h 119 1] Access Width : 00
>>>> [078h 120 8] Address : 0000000000000CF9
>>>>
>>>> [080h 128 1] Value to cause reset : 06
>>>
>>> Hmm, so the FADT says the reset register is listed as supported, and
>>> says writing 0x06 to 0xCF9 is supposed to do it.. That's exactly what
>>> this should do:
>>>
>>> #include<sys/io.h>
>>>
>>> int main() {
>>> iopl(3);
>>> outb(6, 0xcf9);
>>> return 0;
>>> }
>>>
>>> but you said that didn't do anything.. It kind of seems like ACPI
>>> reboot is busted on this machine then, but then I wonder how Windows
>>> manages to work..
>>>
>>
>>
>> alright!! I have a better idea at what this is now..
>> as for the above code, yes this one segfaults,
>> the other code posted on the thread just returns
>> a command prompt(testing:
>
> You get a segfault on that one? Running as root?
>
my bad(tired)I left out iopl(3);
in the code which was giving a segfault.
running the below code(s) just gives a command prompt
int main() {
iopl(3);
outb(0xfe, 0xcf9);
return 0;
}
int main() {
iopl(3);
outb(6, 0xcf9);
return 0;
}
int main() {
iopl(3);
outb(6, 0x64);
return 0;
}
int main() {
iopl(3);
outb(0xfe, 0x64);
return 0;
}
(and yes I made sure I did this as root!!)
:-)
>>
>> #include <sys/io.h>
>>
>> int main() {
>> iopl(3);
>> outb(0xfe, 0xcf9);
>> return 0;
>> }
>> on a dell reboot's as is.)
>>
>> both my macbook, and imac are
>> broken with the above.(but for whatever
>> reason the macbook doesnt need an dmi entry
>> in reboot.c just iMac9,1 etc..)
>>
>> so the address for the CF9 is this:
>>
>> [074h 116 12] Reset Register : <Generic Address Structure>
>> [074h 116 1] Space ID : 01 (SystemIO)
>> [075h 117 1] Bit Width : 08
>> [076h 118 1] Bit Offset : 00
>> [077h 119 1] Access Width : 00
>> [078h 120 8] Address : 0000000000000CF9
>>
>> [080h 128 1] Value to cause reset : 06
>> [081h 129 3] Reserved : 000000
>> [084h 132 8] FACS Address : 00000000BFECD000
>> [08Ch 140 8] DSDT Address : 00000000BFEE0000
>> [094h 148 12] PM1A Event Block : <Generic Address Structure>
>> [094h 148 1] Space ID : 01 (SystemIO)
>> [095h 149 1] Bit Width : 20
>> [096h 150 1] Bit Offset : 00
>> [097h 151 1] Access Width : 00
>> [098h 152 8] Address : 0000000000000400
>>
>> not sure how to read this, but are there
>> two devices here i.g.
>> is the top a cold boot(reset register) and
>> the bottom(value to cause reset) a warm boot?
>
> No, the stuff after "Value to cause reset" is something else entirely.
>
alright!!
Im wondering if KBD_STATUS_REG is wrong on this machine?
and/or 0x472(will look into this stuff)
>>
>> at the moment I'm trying to figure out what/where
>> *((unsigned short *)__va(0x472)) = reboot_mode;
>> 0x472 comes from as well as 0x1234 then
>> #define KBD_STATUS_REG 0x64
>> to see if I can see anything.
>>
>>
>> thanks for the info on this..
>>
>> Justin P. Mattock
>>
>
>
cheers,
Justin P. Mattock
On Wed, Jun 2, 2010 at 6:05 PM, Justin P. Mattock
<[email protected]> wrote:
>>>> Hmm, so the FADT says the reset register is listed as supported, and
>>>> says writing 0x06 to 0xCF9 is supposed to do it.. That's exactly what
>>>> this should do:
>>>>
>>>> #include<sys/io.h>
>>>>
>>>> int main() {
>>>> iopl(3);
>>>> outb(6, 0xcf9);
>>>> return 0;
>>>> }
>>>>
>>>> but you said that didn't do anything.. It kind of seems like ACPI
>>>> reboot is busted on this machine then, but then I wonder how Windows
>>>> manages to work..
>>>>
>>>
>>>
>>> alright!! I have a better idea at what this is now..
>>> as for the above code, yes this one segfaults,
>>> the other code posted on the thread just returns
>>> a command prompt(testing:
>>
>> You get a segfault on that one? Running as root?
>>
>
> my bad(tired)I left out iopl(3);
> in the code which was giving a segfault.
>
> running the below code(s) just gives a command prompt
>
> int main() {
> ? ? ? ?iopl(3);
> ? ? ? ?outb(0xfe, 0xcf9);
> ? ? ? ?return 0;
> }
>
> int main() {
> ? ? ? ?iopl(3);
> ? ? ? ?outb(6, 0xcf9);
> ? ? ? ?return 0;
> }
What if you do:
#include <unistd.h>
int main() {
iopl(3);
outb(2, 0xcf9);
sleep(1);
outb(6, 0xcf9);
return 0;
}
That's basically what PCI reboot does.
It's possible it doesn't take the first time - you could try modifying
drivers/acpi/reboot.c to call acpi_reset in a loop instead of just
trying once (assuming you have the patch to default to ACPI reboot
enabled).
>>> #include <sys/io.h>
>>>
>>> int main() {
>>> iopl(3);
>>> outb(0xfe, 0xcf9);
>>> return 0;
>>> }
>>> on a dell reboot's as is.)
>>>
>>> both my macbook, and imac are
>>> broken with the above.(but for whatever
>>> reason the macbook doesnt need an dmi entry
>>> in reboot.c just iMac9,1 etc..)
>>>
>>> so the address for the CF9 is this:
>>>
>>> [074h 116 12] Reset Register : <Generic Address Structure>
>>> [074h 116 1] Space ID : 01 (SystemIO)
>>> [075h 117 1] Bit Width : 08
>>> [076h 118 1] Bit Offset : 00
>>> [077h 119 1] Access Width : 00
>>> [078h 120 8] Address : 0000000000000CF9
>>>
>>> [080h 128 1] Value to cause reset : 06
>>> [081h 129 3] Reserved : 000000
>>> [084h 132 8] FACS Address : 00000000BFECD000
>>> [08Ch 140 8] DSDT Address : 00000000BFEE0000
>>> [094h 148 12] PM1A Event Block : <Generic Address Structure>
>>> [094h 148 1] Space ID : 01 (SystemIO)
>>> [095h 149 1] Bit Width : 20
>>> [096h 150 1] Bit Offset : 00
>>> [097h 151 1] Access Width : 00
>>> [098h 152 8] Address : 0000000000000400
>>>
>>> not sure how to read this, but are there
>>> two devices here i.g.
>>> is the top a cold boot(reset register) and
>>> the bottom(value to cause reset) a warm boot?
>>
>> No, the stuff after "Value to cause reset" is something else entirely.
>>
> alright!!
> Im wondering if KBD_STATUS_REG is wrong on this machine?
> and/or 0x472(will look into this stuff)
>>>
>>> at the moment I'm trying to figure out what/where
>>> *((unsigned short *)__va(0x472)) = reboot_mode;
>>> 0x472 comes from as well as 0x1234 then
>>> #define KBD_STATUS_REG 0x64
>>> to see if I can see anything.
>>>
>>>
>>> thanks for the info on this..
>>>
>>> Justin P. Mattock
>>>
>>
>>
>
> cheers,
>
> Justin P. Mattock
>
On 06/02/2010 05:20 PM, Robert Hancock wrote:
> On Wed, Jun 2, 2010 at 6:05 PM, Justin P. Mattock
> <[email protected]> wrote:
>>>>> Hmm, so the FADT says the reset register is listed as supported, and
>>>>> says writing 0x06 to 0xCF9 is supposed to do it.. That's exactly what
>>>>> this should do:
>>>>>
>>>>> #include<sys/io.h>
>>>>>
>>>>> int main() {
>>>>> iopl(3);
>>>>> outb(6, 0xcf9);
>>>>> return 0;
>>>>> }
>>>>>
>>>>> but you said that didn't do anything.. It kind of seems like ACPI
>>>>> reboot is busted on this machine then, but then I wonder how Windows
>>>>> manages to work..
>>>>>
>>>>
>>>>
>>>> alright!! I have a better idea at what this is now..
>>>> as for the above code, yes this one segfaults,
>>>> the other code posted on the thread just returns
>>>> a command prompt(testing:
>>>
>>> You get a segfault on that one? Running as root?
>>>
>>
>> my bad(tired)I left out iopl(3);
>> in the code which was giving a segfault.
>>
>> running the below code(s) just gives a command prompt
>>
>> int main() {
>> iopl(3);
>> outb(0xfe, 0xcf9);
>> return 0;
>> }
>>
>> int main() {
>> iopl(3);
>> outb(6, 0xcf9);
>> return 0;
>> }
>
> What if you do:
>
> #include<unistd.h>
>
> int main() {
> iopl(3);
> outb(2, 0xcf9);
> sleep(1);
> outb(6, 0xcf9);
> return 0;
> }
>
> That's basically what PCI reboot does.
>
> It's possible it doesn't take the first time - you could try modifying
> drivers/acpi/reboot.c to call acpi_reset in a loop instead of just
> trying once (assuming you have the patch to default to ACPI reboot
> enabled).
>
the above code reboot's the machine as it should..
I can look at that(need to take a break first though)
and see..
what about the whole kbd mechanism(0x64) give the info I provided
does it look possible, or is this machine strictly on cf9?
cheers,
Justin P. Mattock
On 06/02/2010 06:27 PM, Justin P. Mattock wrote:
> On 06/02/2010 05:20 PM, Robert Hancock wrote:
>> On Wed, Jun 2, 2010 at 6:05 PM, Justin P. Mattock
>> <[email protected]> wrote:
>>>>>> Hmm, so the FADT says the reset register is listed as supported, and
>>>>>> says writing 0x06 to 0xCF9 is supposed to do it.. That's exactly what
>>>>>> this should do:
>>>>>>
>>>>>> #include<sys/io.h>
>>>>>>
>>>>>> int main() {
>>>>>> iopl(3);
>>>>>> outb(6, 0xcf9);
>>>>>> return 0;
>>>>>> }
>>>>>>
>>>>>> but you said that didn't do anything.. It kind of seems like ACPI
>>>>>> reboot is busted on this machine then, but then I wonder how Windows
>>>>>> manages to work..
>>>>>>
>>>>>
>>>>>
>>>>> alright!! I have a better idea at what this is now..
>>>>> as for the above code, yes this one segfaults,
>>>>> the other code posted on the thread just returns
>>>>> a command prompt(testing:
>>>>
>>>> You get a segfault on that one? Running as root?
>>>>
>>>
>>> my bad(tired)I left out iopl(3);
>>> in the code which was giving a segfault.
>>>
>>> running the below code(s) just gives a command prompt
>>>
>>> int main() {
>>> iopl(3);
>>> outb(0xfe, 0xcf9);
>>> return 0;
>>> }
>>>
>>> int main() {
>>> iopl(3);
>>> outb(6, 0xcf9);
>>> return 0;
>>> }
>>
>> What if you do:
>>
>> #include<unistd.h>
>>
>> int main() {
>> iopl(3);
>> outb(2, 0xcf9);
>> sleep(1);
>> outb(6, 0xcf9);
>> return 0;
>> }
>>
>> That's basically what PCI reboot does.
>>
>> It's possible it doesn't take the first time - you could try modifying
>> drivers/acpi/reboot.c to call acpi_reset in a loop instead of just
>> trying once (assuming you have the patch to default to ACPI reboot
>> enabled).
>>
>
> the above code reboot's the machine as it should..
> I can look at that(need to take a break first though)
> and see..
>
> what about the whole kbd mechanism(0x64) give the info I provided
> does it look possible, or is this machine strictly on cf9?
The keyboard controller reset is the kernel default, so I assume that
doesn't work on this machine or else this wouldn't have come up in the
first place..
On 06/02/2010 05:34 PM, Robert Hancock wrote:
> On 06/02/2010 06:27 PM, Justin P. Mattock wrote:
>> On 06/02/2010 05:20 PM, Robert Hancock wrote:
>>> On Wed, Jun 2, 2010 at 6:05 PM, Justin P. Mattock
>>> <[email protected]> wrote:
>>>>>>> Hmm, so the FADT says the reset register is listed as supported, and
>>>>>>> says writing 0x06 to 0xCF9 is supposed to do it.. That's exactly
>>>>>>> what
>>>>>>> this should do:
>>>>>>>
>>>>>>> #include<sys/io.h>
>>>>>>>
>>>>>>> int main() {
>>>>>>> iopl(3);
>>>>>>> outb(6, 0xcf9);
>>>>>>> return 0;
>>>>>>> }
>>>>>>>
>>>>>>> but you said that didn't do anything.. It kind of seems like ACPI
>>>>>>> reboot is busted on this machine then, but then I wonder how Windows
>>>>>>> manages to work..
>>>>>>>
>>>>>>
>>>>>>
>>>>>> alright!! I have a better idea at what this is now..
>>>>>> as for the above code, yes this one segfaults,
>>>>>> the other code posted on the thread just returns
>>>>>> a command prompt(testing:
>>>>>
>>>>> You get a segfault on that one? Running as root?
>>>>>
>>>>
>>>> my bad(tired)I left out iopl(3);
>>>> in the code which was giving a segfault.
>>>>
>>>> running the below code(s) just gives a command prompt
>>>>
>>>> int main() {
>>>> iopl(3);
>>>> outb(0xfe, 0xcf9);
>>>> return 0;
>>>> }
>>>>
>>>> int main() {
>>>> iopl(3);
>>>> outb(6, 0xcf9);
>>>> return 0;
>>>> }
>>>
>>> What if you do:
>>>
>>> #include<unistd.h>
>>>
>>> int main() {
>>> iopl(3);
>>> outb(2, 0xcf9);
>>> sleep(1);
>>> outb(6, 0xcf9);
>>> return 0;
>>> }
>>>
>>> That's basically what PCI reboot does.
>>>
>>> It's possible it doesn't take the first time - you could try modifying
>>> drivers/acpi/reboot.c to call acpi_reset in a loop instead of just
>>> trying once (assuming you have the patch to default to ACPI reboot
>>> enabled).
>>>
>>
>> the above code reboot's the machine as it should..
>> I can look at that(need to take a break first though)
>> and see..
>>
>> what about the whole kbd mechanism(0x64) give the info I provided
>> does it look possible, or is this machine strictly on cf9?
>
> The keyboard controller reset is the kernel default, so I assume that
> doesn't work on this machine or else this wouldn't have come up in the
> first place..
>
that's what I'm trying to figure out i.g. how to find
that value(is where I'm at).. tried showkey
but didn't see anything, looked in the dsdt but
didn't see anything that sticks out(to my knowledge)
in the area of 0x64 or 0x472
From what I've read, having a cold boot, and or
a pci/cpu(trip) seems a bit harsh on the equipment
as opposed to a warm boot(hard disk's shutdown etc...)
but I could be wrong in that area..
Justin P. Mattock
On Wed, Jun 02, 2010 at 05:27:22PM -0700, Justin P. Mattock wrote:
> On 06/02/2010 05:20 PM, Robert Hancock wrote:
>> #include<unistd.h>
>>
>> int main() {
>> iopl(3);
>> outb(2, 0xcf9);
>> sleep(1);
>> outb(6, 0xcf9);
>> return 0;
>> }
>>
>> That's basically what PCI reboot does.
>
> the above code reboot's the machine as it should..
> I can look at that(need to take a break first though)
> and see..
That's pretty infuriating. The ACPI-provided definition doesn't work,
and there's no ACPI mechanism for expressing the more complex cf9
behaviour. Windows doesn't appear to special case this, so we're
probably left trying to figure out why the keyboard controller method
doesn't work. Sigh.
--
Matthew Garrett | [email protected]
On 06/02/2010 06:37 PM, Matthew Garrett wrote:
> On Wed, Jun 02, 2010 at 05:27:22PM -0700, Justin P. Mattock wrote:
>> On 06/02/2010 05:20 PM, Robert Hancock wrote:
>>> #include<unistd.h>
>>>
>>> int main() {
>>> iopl(3);
>>> outb(2, 0xcf9);
>>> sleep(1);
>>> outb(6, 0xcf9);
>>> return 0;
>>> }
>>>
>>> That's basically what PCI reboot does.
>>
>> the above code reboot's the machine as it should..
>> I can look at that(need to take a break first though)
>> and see..
>
> That's pretty infuriating. The ACPI-provided definition doesn't work,
> and there's no ACPI mechanism for expressing the more complex cf9
> behaviour. Windows doesn't appear to special case this, so we're
> probably left trying to figure out why the keyboard controller method
> doesn't work. Sigh.
>
any ideas on how to find that value?
(using showkey does give values
but I don't think it gives the low level
value as this(but could be wrong)).
Justin P. Mattock
On Wed, Jun 2, 2010 at 7:37 PM, Matthew Garrett <[email protected]> wrote:
> On Wed, Jun 02, 2010 at 05:27:22PM -0700, Justin P. Mattock wrote:
>> On 06/02/2010 05:20 PM, Robert Hancock wrote:
>>> #include<unistd.h>
>>>
>>> int main() {
>>> ? ? ? ? ?iopl(3);
>>> ? ? ? ? ?outb(2, 0xcf9);
>>> ? ? ? ? ?sleep(1);
>>> ? ? ? ? ?outb(6, 0xcf9);
>>> ? ? ? ? ?return 0;
>>> }
>>>
>>> That's basically what PCI reboot does.
>>
>> the above code reboot's the machine as it should..
>> I can look at that(need to take a break first though)
>> and see..
>
> That's pretty infuriating. The ACPI-provided definition doesn't work,
> and there's no ACPI mechanism for expressing the more complex cf9
> behaviour. Windows doesn't appear to special case this, so we're
> probably left trying to figure out why the keyboard controller method
> doesn't work. Sigh.
Do these Macs even have a PC keyboard controller? A recent thread on
PS/2 keyboard/mouse controller probing suggests they may not..
Justin, what happens if you try the simple outb(6, 0xcf9) test program
multiple times, does that do anything?
On Wed, Jun 02, 2010 at 07:47:17PM -0600, Robert Hancock wrote:
> On Wed, Jun 2, 2010 at 7:37 PM, Matthew Garrett <[email protected]> wrote:
> > That's pretty infuriating. The ACPI-provided definition doesn't work,
> > and there's no ACPI mechanism for expressing the more complex cf9
> > behaviour. Windows doesn't appear to special case this, so we're
> > probably left trying to figure out why the keyboard controller method
> > doesn't work. Sigh.
>
> Do these Macs even have a PC keyboard controller? A recent thread on
> PS/2 keyboard/mouse controller probing suggests they may not..
Possibly an SMM trap...
> Justin, what happens if you try the simple outb(6, 0xcf9) test program
> multiple times, does that do anything?
Huh. That might work, yes. Windows does the ACPI write, an i8042 write,
the ACPI write, another i8042 write and then gives up. If that happens
sufficiently quickly, this might get us somewhere. Justin, can you try:
#include <sys/io.h>
#include <unistd.h>
int main() {
iopl(3);
outb(6, 0xcf9);
usleep(100);
outb(6, 0xcf9);
return 0;
}
and see if that reboots?
--
Matthew Garrett | [email protected]
On 06/02/2010 06:47 PM, Robert Hancock wrote:
> On Wed, Jun 2, 2010 at 7:37 PM, Matthew Garrett<[email protected]> wrote:
>> On Wed, Jun 02, 2010 at 05:27:22PM -0700, Justin P. Mattock wrote:
>>> On 06/02/2010 05:20 PM, Robert Hancock wrote:
>>>> #include<unistd.h>
>>>>
>>>> int main() {
>>>> iopl(3);
>>>> outb(2, 0xcf9);
>>>> sleep(1);
>>>> outb(6, 0xcf9);
>>>> return 0;
>>>> }
>>>>
>>>> That's basically what PCI reboot does.
>>>
>>> the above code reboot's the machine as it should..
>>> I can look at that(need to take a break first though)
>>> and see..
>>
>> That's pretty infuriating. The ACPI-provided definition doesn't work,
>> and there's no ACPI mechanism for expressing the more complex cf9
>> behaviour. Windows doesn't appear to special case this, so we're
>> probably left trying to figure out why the keyboard controller method
>> doesn't work. Sigh.
>
> Do these Macs even have a PC keyboard controller? A recent thread on
> PS/2 keyboard/mouse controller probing suggests they may not..
>
> Justin, what happens if you try the simple outb(6, 0xcf9) test program
> multiple times, does that do anything?
>
this reboots the system
int main() {
iopl(3);
outb(6, 0xcf9);
return 0;
}
Justin P. Mattock
On Wed, Jun 2, 2010 at 8:00 PM, Justin P. Mattock
<[email protected]> wrote:
> On 06/02/2010 06:47 PM, Robert Hancock wrote:
>>
>> On Wed, Jun 2, 2010 at 7:37 PM, Matthew Garrett<[email protected]>
>> ?wrote:
>>>
>>> On Wed, Jun 02, 2010 at 05:27:22PM -0700, Justin P. Mattock wrote:
>>>>
>>>> On 06/02/2010 05:20 PM, Robert Hancock wrote:
>>>>>
>>>>> #include<unistd.h>
>>>>>
>>>>> int main() {
>>>>> ? ? ? ? ?iopl(3);
>>>>> ? ? ? ? ?outb(2, 0xcf9);
>>>>> ? ? ? ? ?sleep(1);
>>>>> ? ? ? ? ?outb(6, 0xcf9);
>>>>> ? ? ? ? ?return 0;
>>>>> }
>>>>>
>>>>> That's basically what PCI reboot does.
>>>>
>>>> the above code reboot's the machine as it should..
>>>> I can look at that(need to take a break first though)
>>>> and see..
>>>
>>> That's pretty infuriating. The ACPI-provided definition doesn't work,
>>> and there's no ACPI mechanism for expressing the more complex cf9
>>> behaviour. Windows doesn't appear to special case this, so we're
>>> probably left trying to figure out why the keyboard controller method
>>> doesn't work. Sigh.
>>
>> Do these Macs even have a PC keyboard controller? A recent thread on
>> PS/2 keyboard/mouse controller probing suggests they may not..
>>
>> Justin, what happens if you try the simple outb(6, 0xcf9) test program
>> multiple times, does that do anything?
>>
>
>
> this reboots the system
>
>
> int main() {
> ? ? ? ? ? iopl(3);
> ? ? ? ? ? outb(6, 0xcf9);
> ? ? ? ? ? return 0;
> }
On a single try, or multiple times? (You tried that one before once
and it didn't work, right?)
On 06/02/2010 06:56 PM, Matthew Garrett wrote:
> On Wed, Jun 02, 2010 at 07:47:17PM -0600, Robert Hancock wrote:
>> On Wed, Jun 2, 2010 at 7:37 PM, Matthew Garrett<[email protected]> wrote:
>>> That's pretty infuriating. The ACPI-provided definition doesn't work,
>>> and there's no ACPI mechanism for expressing the more complex cf9
>>> behaviour. Windows doesn't appear to special case this, so we're
>>> probably left trying to figure out why the keyboard controller method
>>> doesn't work. Sigh.
>>
>> Do these Macs even have a PC keyboard controller? A recent thread on
>> PS/2 keyboard/mouse controller probing suggests they may not..
>
> Possibly an SMM trap...
>
>> Justin, what happens if you try the simple outb(6, 0xcf9) test program
>> multiple times, does that do anything?
>
> Huh. That might work, yes. Windows does the ACPI write, an i8042 write,
> the ACPI write, another i8042 write and then gives up. If that happens
> sufficiently quickly, this might get us somewhere. Justin, can you try:
>
> #include<sys/io.h>
> #include<unistd.h>
>
> int main() {
> iopl(3);
> outb(6, 0xcf9);
> usleep(100);
> outb(6, 0xcf9);
> return 0;
> }
>
> and see if that reboots?
>
this thing is wacked out
this just rebooted the system:
int main() {
iopl(3);
outb(6, 0xcf9);
return 0;
}
and now it's motionless
(just a command prompt).
Justin P. Mattock
On Wed, Jun 2, 2010 at 7:56 PM, Matthew Garrett <[email protected]> wrote:
> On Wed, Jun 02, 2010 at 07:47:17PM -0600, Robert Hancock wrote:
>> On Wed, Jun 2, 2010 at 7:37 PM, Matthew Garrett <[email protected]> wrote:
>> > That's pretty infuriating. The ACPI-provided definition doesn't work,
>> > and there's no ACPI mechanism for expressing the more complex cf9
>> > behaviour. Windows doesn't appear to special case this, so we're
>> > probably left trying to figure out why the keyboard controller method
>> > doesn't work. Sigh.
>>
>> Do these Macs even have a PC keyboard controller? A recent thread on
>> PS/2 keyboard/mouse controller probing suggests they may not..
>
> Possibly an SMM trap...
>
>> Justin, what happens if you try the simple outb(6, 0xcf9) test program
>> multiple times, does that do anything?
>
> Huh. That might work, yes. Windows does the ACPI write, an i8042 write,
> the ACPI write, another i8042 write and then gives up. If that happens
> sufficiently quickly, this might get us somewhere. Justin, can you try:
If that's the sequence Windows is using then I'm thinking that's
likely what we should be doing as well..
On 06/02/2010 06:47 PM, Robert Hancock wrote:
> On Wed, Jun 2, 2010 at 7:37 PM, Matthew Garrett<[email protected]> wrote:
>> On Wed, Jun 02, 2010 at 05:27:22PM -0700, Justin P. Mattock wrote:
>>> On 06/02/2010 05:20 PM, Robert Hancock wrote:
>>>> #include<unistd.h>
>>>>
>>>> int main() {
>>>> iopl(3);
>>>> outb(2, 0xcf9);
>>>> sleep(1);
>>>> outb(6, 0xcf9);
>>>> return 0;
>>>> }
>>>>
>>>> That's basically what PCI reboot does.
>>>
>>> the above code reboot's the machine as it should..
>>> I can look at that(need to take a break first though)
>>> and see..
>>
>> That's pretty infuriating. The ACPI-provided definition doesn't work,
>> and there's no ACPI mechanism for expressing the more complex cf9
>> behaviour. Windows doesn't appear to special case this, so we're
>> probably left trying to figure out why the keyboard controller method
>> doesn't work. Sigh.
>
> Do these Macs even have a PC keyboard controller? A recent thread on
> PS/2 keyboard/mouse controller probing suggests they may not..
>
> Justin, what happens if you try the simple outb(6, 0xcf9) test program
> multiple times, does that do anything?
>
as soon as I change:
int main() {
iopl(3);
outb(6, 0xcf9);
usleep(100);
outb(6, 0xcf9);
return 0;
}
(the above gave a command prompt
with numerous tries)
to:
int main() {
iopl(3);
outb(2, 0xcf9);
usleep(100);
outb(6, 0xcf9);
return 0;
}
it worked..(on the first try)
but still am confused as
to why I tried: outb(2, 0xcf9);
with nothing happening.
(Maybe something in there
is changing each boot or something.)
Justin P. Mattock
Justin P. Mattock
On 06/02/2010 07:05 PM, Robert Hancock wrote:
> On Wed, Jun 2, 2010 at 8:00 PM, Justin P. Mattock
> <[email protected]> wrote:
>> On 06/02/2010 06:47 PM, Robert Hancock wrote:
>>>
>>> On Wed, Jun 2, 2010 at 7:37 PM, Matthew Garrett<[email protected]>
>>> wrote:
>>>>
>>>> On Wed, Jun 02, 2010 at 05:27:22PM -0700, Justin P. Mattock wrote:
>>>>>
>>>>> On 06/02/2010 05:20 PM, Robert Hancock wrote:
>>>>>>
>>>>>> #include<unistd.h>
>>>>>>
>>>>>> int main() {
>>>>>> iopl(3);
>>>>>> outb(2, 0xcf9);
>>>>>> sleep(1);
>>>>>> outb(6, 0xcf9);
>>>>>> return 0;
>>>>>> }
>>>>>>
>>>>>> That's basically what PCI reboot does.
>>>>>
>>>>> the above code reboot's the machine as it should..
>>>>> I can look at that(need to take a break first though)
>>>>> and see..
>>>>
>>>> That's pretty infuriating. The ACPI-provided definition doesn't work,
>>>> and there's no ACPI mechanism for expressing the more complex cf9
>>>> behaviour. Windows doesn't appear to special case this, so we're
>>>> probably left trying to figure out why the keyboard controller method
>>>> doesn't work. Sigh.
>>>
>>> Do these Macs even have a PC keyboard controller? A recent thread on
>>> PS/2 keyboard/mouse controller probing suggests they may not..
>>>
>>> Justin, what happens if you try the simple outb(6, 0xcf9) test program
>>> multiple times, does that do anything?
>>>
>>
>>
>> this reboots the system
>>
>>
>> int main() {
>> iopl(3);
>> outb(6, 0xcf9);
>> return 0;
>> }
>
> On a single try, or multiple times? (You tried that one before once
> and it didn't work, right?)
>
yeah single try. then I rebooted
and it was like dead or something.
Justin P. Mattock
On 06/02/2010 07:15 PM, Justin P. Mattock wrote:
> On 06/02/2010 06:47 PM, Robert Hancock wrote:
>> On Wed, Jun 2, 2010 at 7:37 PM, Matthew Garrett<[email protected]>
>> wrote:
>>> On Wed, Jun 02, 2010 at 05:27:22PM -0700, Justin P. Mattock wrote:
>>>> On 06/02/2010 05:20 PM, Robert Hancock wrote:
>>>>> #include<unistd.h>
>>>>>
>>>>> int main() {
>>>>> iopl(3);
>>>>> outb(2, 0xcf9);
>>>>> sleep(1);
>>>>> outb(6, 0xcf9);
>>>>> return 0;
>>>>> }
>>>>>
>>>>> That's basically what PCI reboot does.
>>>>
>>>> the above code reboot's the machine as it should..
>>>> I can look at that(need to take a break first though)
>>>> and see..
>>>
>>> That's pretty infuriating. The ACPI-provided definition doesn't work,
>>> and there's no ACPI mechanism for expressing the more complex cf9
>>> behaviour. Windows doesn't appear to special case this, so we're
>>> probably left trying to figure out why the keyboard controller method
>>> doesn't work. Sigh.
>>
>> Do these Macs even have a PC keyboard controller? A recent thread on
>> PS/2 keyboard/mouse controller probing suggests they may not..
>>
>> Justin, what happens if you try the simple outb(6, 0xcf9) test program
>> multiple times, does that do anything?
>>
>
>
> as soon as I change:
>
> int main() {
> iopl(3);
> outb(6, 0xcf9);
> usleep(100);
> outb(6, 0xcf9);
> return 0;
> }
> (the above gave a command prompt
> with numerous tries)
> to:
>
> int main() {
> iopl(3);
> outb(2, 0xcf9);
> usleep(100);
> outb(6, 0xcf9);
> return 0;
> }
>
> it worked..(on the first try)
>
just rebooted, and tried the one that worked,
had no response(just a command prompt) even though
it rebooted the system prior too.
> but still am confused as
> to why I tried: outb(2, 0xcf9);
> with nothing happening.
> (Maybe something in there
> is changing each boot or something.)
>
something is changing in there it seems.
Justin P. Mattock
On Wed, Jun 02, 2010 at 07:15:36PM -0700, Justin P. Mattock wrote:
> as soon as I change:
>
> int main() {
> iopl(3);
> outb(6, 0xcf9);
> usleep(100);
> outb(6, 0xcf9);
> return 0;
> }
> (the above gave a command prompt
> with numerous tries)
Ok, so it's not that straghtforward. Sigh. There's various hacky
workarounds we could do here, but Windows doesn't seem to do them so I
lean towards suspecting that there's something wrong with our keyboard
controller reboot mechanism. I'll try doing some more tracing.
--
Matthew Garrett | [email protected]
On 06/02/2010 07:18 PM, Matthew Garrett wrote:
> On Wed, Jun 02, 2010 at 07:15:36PM -0700, Justin P. Mattock wrote:
>> as soon as I change:
>>
>> int main() {
>> iopl(3);
>> outb(6, 0xcf9);
>> usleep(100);
>> outb(6, 0xcf9);
>> return 0;
>> }
>> (the above gave a command prompt
>> with numerous tries)
>
> Ok, so it's not that straghtforward. Sigh. There's various hacky
> workarounds we could do here, but Windows doesn't seem to do them so I
> lean towards suspecting that there's something wrong with our keyboard
> controller reboot mechanism. I'll try doing some more tracing.
>
I'll keep looking around as well(the best I can)
FWIW not sure if this means anything but
grep PS *.dsl
gives:
SPST, 1,
PSVT, 8,
PSCL, 8,
APPS, 1,
PSI0, 8,
PSI1, 8,
If (PSI0)
Store (0x00, PSI0)
Return (CRS (PSI0))
Return (CRSI (PSI0))
Store (SRS (Arg0), PSI0)
Store (SRSI (Arg0), PSI0)
If (PSI1)
Store (0x00, PSI1)
Return (CRS (PSI1))
Return (CRSI (PSI1))
Store (SRS (Arg0), PSI1)
Store (SRSI (Arg0), PSI1)
Method (_PSW, 1, NotSerialized)
Name (PSIT, 0x00)
Method (_PS0, 0, Serialized)
Method (_PS3, 0, Serialized)
Method (_PS0, 0, Serialized)
Store (0x00, APPS)
Method (_PS3, 0, Serialized)
Store (0x01, APPS)
there's no such thing as a PS/3 is there?
Justin P. Mattock
On Thu, 3 Jun 2010 03:18:51 +0100
Matthew Garrett <[email protected]> wrote:
> On Wed, Jun 02, 2010 at 07:15:36PM -0700, Justin P. Mattock wrote:
> > as soon as I change:
> >
> > int main() {
> > iopl(3);
> > outb(6, 0xcf9);
> > usleep(100);
> > outb(6, 0xcf9);
> > return 0;
> > }
> > (the above gave a command prompt
> > with numerous tries)
>
> Ok, so it's not that straghtforward. Sigh. There's various hacky
> workarounds we could do here, but Windows doesn't seem to do them so I
> lean towards suspecting that there's something wrong with our keyboard
> controller reboot mechanism. I'll try doing some more tracing.
At least some PCs you need to issue the reboot outb calls on the boot
processor so the userspace tests won't be reliable.
On 06/03/2010 02:54 AM, Alan Cox wrote:
> On Thu, 3 Jun 2010 03:18:51 +0100
> Matthew Garrett<[email protected]> wrote:
>
>> On Wed, Jun 02, 2010 at 07:15:36PM -0700, Justin P. Mattock wrote:
>>> as soon as I change:
>>>
>>> int main() {
>>> iopl(3);
>>> outb(6, 0xcf9);
>>> usleep(100);
>>> outb(6, 0xcf9);
>>> return 0;
>>> }
>>> (the above gave a command prompt
>>> with numerous tries)
>>
>> Ok, so it's not that straghtforward. Sigh. There's various hacky
>> workarounds we could do here, but Windows doesn't seem to do them so I
>> lean towards suspecting that there's something wrong with our keyboard
>> controller reboot mechanism. I'll try doing some more tracing.
>
> At least some PCs you need to issue the reboot outb calls on the boot
> processor so the userspace tests won't be reliable.
>
well.. the userspace is unreliable from over here..
but if were looking at the issue we might as well
look at the whole problem at hand..
i.g. solving the problem with apple, and solving the
problem with the others..(basically getting rid of this
whole dmi entry list all together..(or at-least most of it)..
but might be a bit much..
Justin P. Mattock
On Thu, Jun 03, 2010 at 10:54:38AM +0100, Alan Cox wrote:
> At least some PCs you need to issue the reboot outb calls on the boot
> processor so the userspace tests won't be reliable.
The cf9 write is supposed to be handled by the chipset rather than via
SMM, I believe? The SMM code I've seen for reboots seems to implement
the actual reboot by hitting that port itself...
--
Matthew Garrett | [email protected]
On Thu, Jun 3, 2010 at 3:54 AM, Alan Cox <[email protected]> wrote:
> On Thu, 3 Jun 2010 03:18:51 +0100
> Matthew Garrett <[email protected]> wrote:
>
>> On Wed, Jun 02, 2010 at 07:15:36PM -0700, Justin P. Mattock wrote:
>> > as soon as I change:
>> >
>> > int main() {
>> > ? ? iopl(3);
>> > ? ? outb(6, 0xcf9);
>> > ? ? usleep(100);
>> > ? ? outb(6, 0xcf9);
>> > ? ? return 0;
>> > }
>> > (the above gave a command prompt
>> > with numerous tries)
>>
>> Ok, so it's not that straghtforward. Sigh. There's various hacky
>> workarounds we could do here, but Windows doesn't seem to do them so I
>> lean towards suspecting that there's something wrong with our keyboard
>> controller reboot mechanism. I'll try doing some more tracing.
>
> At least some PCs you need to issue the reboot outb calls on the boot
> processor so the userspace tests won't be reliable.
In that case you could presumably run them:
taskset 0x00000001 (program name)
and see if that changes anything.