> I'll contact
> the people I know in Dell and see if I can find anyone from the firmware
> division who'll actually talk to us.
What about now?
As a side note, OT, but:
http://arstechnica.com/gadgets/2014/04/fast-but-compromised-gigabytes-amd-powered-mini-gaming-pc-reviewed/?comments=1
(notice
I'll contact
the people I know in Dell and see if I can find anyone from the firmware
division who'll actually talk to us.
What about now?
As a side note, OT, but:
http://arstechnica.com/gadgets/2014/04/fast-but-compromised-gigabytes-amd-powered-mini-gaming-pc-reviewed/?comments=1
(notice
On Fri, Apr 4, 2014 at 9:31 AM, H. Peter Anvin wrote:
> On 04/04/2014 08:45 AM, Matthew Garrett wrote:
>>
>> Windows hits the keyboard controller and then tries the ACPI vector. It
>> then sleeps for a short period, then tries the keyboard controller again
>> and the ACPI vector again.
>>
>
> So
On Fri, Apr 4, 2014 at 9:21 AM, Matthew Garrett wrote:
>
> Because Windows doesn't use CF9 but machines reboot anyway. That
> shouldn't be a controversial point of view.
No, that's not a controversial view.
But it's not the case for us, and I haven't seen a patch to make us
work more like
On Fri, Apr 04, 2014 at 07:44:37PM +0200, Ingo Molnar wrote:
>
> Before any other change is done beyond the revert of this latest
> broken commit.
The commit in question was the one that added the misleading text to the
comment. I'm sorry, I should have caught that.
--
Matthew Garrett |
* H. Peter Anvin wrote:
> The comment header is bogus... it describes what we do, not what
> Windows does.
That comment certainly pretends to describe Windows behavior and then
it goes to outline the differences in Linux behavior:
/*
* Windows compatible x86 hardware expects the following
* H. Peter Anvin wrote:
> On April 4, 2014 9:32:58 AM PDT, Matthew Garrett wrote:
>
> > Windows does ACPI first, so no. And the Dells were broken even
> > before we moved ACPI up the list.
>
> That's not what you said a few posts ago.
Exactly, the claim ws:
"Windows hits the keyboard
The comment header is bogus... it describes what we do, not what Windows does.
On April 4, 2014 10:34:31 AM PDT, Ingo Molnar wrote:
>
>* Matthew Garrett wrote:
>
>> On Fri, Apr 04, 2014 at 08:13:48AM -0700, H. Peter Anvin wrote:
>> > On 04/04/2014 08:12 AM, Matthew Garrett wrote:
>> > > On Fri,
* Matthew Garrett wrote:
> On Fri, Apr 04, 2014 at 08:13:48AM -0700, H. Peter Anvin wrote:
> > On 04/04/2014 08:12 AM, Matthew Garrett wrote:
> > > On Fri, Apr 04, 2014 at 09:27:48AM +0800, Li, Aubrey wrote:
> > >
> > >> The current situation is,
> > >> - we have one(do we know more?)
That's not what you said a few posts ago.
On April 4, 2014 9:32:58 AM PDT, Matthew Garrett wrote:
>Windows does ACPI first, so no. And the Dells were broken even before
>we moved ACPI up the list.
--
Sent from my mobile phone. Please pardon brevity and lack of formatting.
--
To unsubscribe
On 04/04/2014 08:45 AM, Matthew Garrett wrote:
>
> Windows hits the keyboard controller and then tries the ACPI vector. It
> then sleeps for a short period, then tries the keyboard controller again
> and the ACPI vector again.
>
So do you think we should move the KBC upward in our priority
On Fri, Apr 04, 2014 at 09:09:32AM -0700, Linus Torvalds wrote:
> On Fri, Apr 4, 2014 at 8:45 AM, Matthew Garrett wrote:
> >
> > Which is almost certainly because the other reboot methods are trapping
> > into SMI and hitting some hardware that we've left in a different state
> > to Windows.
>
>
On Fri, Apr 4, 2014 at 8:45 AM, Matthew Garrett wrote:
>
> Which is almost certainly because the other reboot methods are trapping
> into SMI and hitting some hardware that we've left in a different state
> to Windows.
Why are you making up these completely invalid arguments? Because you
are
On 04.04.2014 17:45, Matthew Garrett wrote:
On Fri, Apr 04, 2014 at 08:38:42AM -0700, Linus Torvalds wrote:
On Fri, Apr 4, 2014 at 8:12 AM, Matthew Garrett wrote:
Production hardware should never require CF9.
That's total BS.
The fact is, we may be doing something wrong, but ACPI fails on
On Fri, 04 Apr 2014 08:39:51 -0700
"H. Peter Anvin" wrote:
> There are several platforms where the default boot method invokes an SMM
> handler which blithly assumes that the hardware is in whatever state
> Windows leaves it in, and hangs otherwise. This seems to include nearly
> all Dell
On Fri, Apr 04, 2014 at 08:38:42AM -0700, Linus Torvalds wrote:
> On Fri, Apr 4, 2014 at 8:12 AM, Matthew Garrett wrote:
> >
> > Production hardware should never require CF9.
>
> That's total BS.
>
> The fact is, we may be doing something wrong, but ACPI fails on a
> *lot* of systems. A huge
On Fri, Apr 04, 2014 at 08:39:51AM -0700, H. Peter Anvin wrote:
>
> There are several platforms where the default boot method invokes an SMM
> handler which blithly assumes that the hardware is in whatever state
> Windows leaves it in, and hangs otherwise. This seems to include nearly
> all Dell
On 04/04/2014 08:36 AM, Matthew Garrett wrote:
> On Fri, Apr 04, 2014 at 08:13:48AM -0700, H. Peter Anvin wrote:
>> On 04/04/2014 08:12 AM, Matthew Garrett wrote:
>>> On Fri, Apr 04, 2014 at 09:27:48AM +0800, Li, Aubrey wrote:
>>>
The current situation is,
- we have one(do we know more?)
On Fri, Apr 4, 2014 at 8:12 AM, Matthew Garrett wrote:
>
> Production hardware should never require CF9.
That's total BS.
The fact is, we may be doing something wrong, but ACPI fails on a
*lot* of systems. A huge swath of Dell machines in particular for some
reason (laptops, desktops, _and_ now
On Fri, Apr 04, 2014 at 08:13:48AM -0700, H. Peter Anvin wrote:
> On 04/04/2014 08:12 AM, Matthew Garrett wrote:
> > On Fri, Apr 04, 2014 at 09:27:48AM +0800, Li, Aubrey wrote:
> >
> >> The current situation is,
> >> - we have one(do we know more?) preproduction machine hangs by CF9.
> >> - We
On 04/04/2014 08:12 AM, Matthew Garrett wrote:
> On Fri, Apr 04, 2014 at 09:27:48AM +0800, Li, Aubrey wrote:
>
>> The current situation is,
>> - we have one(do we know more?) preproduction machine hangs by CF9.
>> - We have more than one(could be thousand known) production machine
>> works by
On Fri, Apr 04, 2014 at 09:27:48AM +0800, Li, Aubrey wrote:
> The current situation is,
> - we have one(do we know more?) preproduction machine hangs by CF9.
> - We have more than one(could be thousand known) production machine
> works by CF9.
Production hardware should never require CF9.
--
Plenty. It used to be the default reboot method for a long time, but it isn't
anymore for a reason.
On April 3, 2014 11:13:32 PM PDT, Ingo Molnar wrote:
>
>* H. Peter Anvin wrote:
>
>> Keep in mind we already tried CF9 in the default flow and it broke
>> things. I'm willing to wait for
* H. Peter Anvin wrote:
> Keep in mind we already tried CF9 in the default flow and it broke
> things. I'm willing to wait for reports about production machines,
> though, but I fully expect them.
Typically there's nothing particularly weird about preproduction Intel
hardware when it comes
* H. Peter Anvin h...@zytor.com wrote:
Keep in mind we already tried CF9 in the default flow and it broke
things. I'm willing to wait for reports about production machines,
though, but I fully expect them.
Typically there's nothing particularly weird about preproduction Intel
hardware
Plenty. It used to be the default reboot method for a long time, but it isn't
anymore for a reason.
On April 3, 2014 11:13:32 PM PDT, Ingo Molnar mi...@kernel.org wrote:
* H. Peter Anvin h...@zytor.com wrote:
Keep in mind we already tried CF9 in the default flow and it broke
things. I'm
On Fri, Apr 04, 2014 at 09:27:48AM +0800, Li, Aubrey wrote:
The current situation is,
- we have one(do we know more?) preproduction machine hangs by CF9.
- We have more than one(could be thousand known) production machine
works by CF9.
Production hardware should never require CF9.
--
On 04/04/2014 08:12 AM, Matthew Garrett wrote:
On Fri, Apr 04, 2014 at 09:27:48AM +0800, Li, Aubrey wrote:
The current situation is,
- we have one(do we know more?) preproduction machine hangs by CF9.
- We have more than one(could be thousand known) production machine
works by CF9.
On Fri, Apr 04, 2014 at 08:13:48AM -0700, H. Peter Anvin wrote:
On 04/04/2014 08:12 AM, Matthew Garrett wrote:
On Fri, Apr 04, 2014 at 09:27:48AM +0800, Li, Aubrey wrote:
The current situation is,
- we have one(do we know more?) preproduction machine hangs by CF9.
- We have more than
On Fri, Apr 4, 2014 at 8:12 AM, Matthew Garrett mj...@srcf.ucam.org wrote:
Production hardware should never require CF9.
That's total BS.
The fact is, we may be doing something wrong, but ACPI fails on a
*lot* of systems. A huge swath of Dell machines in particular for some
reason (laptops,
On 04/04/2014 08:36 AM, Matthew Garrett wrote:
On Fri, Apr 04, 2014 at 08:13:48AM -0700, H. Peter Anvin wrote:
On 04/04/2014 08:12 AM, Matthew Garrett wrote:
On Fri, Apr 04, 2014 at 09:27:48AM +0800, Li, Aubrey wrote:
The current situation is,
- we have one(do we know more?) preproduction
On Fri, Apr 04, 2014 at 08:38:42AM -0700, Linus Torvalds wrote:
On Fri, Apr 4, 2014 at 8:12 AM, Matthew Garrett mj...@srcf.ucam.org wrote:
Production hardware should never require CF9.
That's total BS.
The fact is, we may be doing something wrong, but ACPI fails on a
*lot* of systems.
On Fri, Apr 04, 2014 at 08:39:51AM -0700, H. Peter Anvin wrote:
There are several platforms where the default boot method invokes an SMM
handler which blithly assumes that the hardware is in whatever state
Windows leaves it in, and hangs otherwise. This seems to include nearly
all Dell
On Fri, 04 Apr 2014 08:39:51 -0700
H. Peter Anvin h...@zytor.com wrote:
There are several platforms where the default boot method invokes an SMM
handler which blithly assumes that the hardware is in whatever state
Windows leaves it in, and hangs otherwise. This seems to include nearly
all
On 04.04.2014 17:45, Matthew Garrett wrote:
On Fri, Apr 04, 2014 at 08:38:42AM -0700, Linus Torvalds wrote:
On Fri, Apr 4, 2014 at 8:12 AM, Matthew Garrett mj...@srcf.ucam.org wrote:
Production hardware should never require CF9.
That's total BS.
The fact is, we may be doing something wrong,
On Fri, Apr 4, 2014 at 8:45 AM, Matthew Garrett mj...@srcf.ucam.org wrote:
Which is almost certainly because the other reboot methods are trapping
into SMI and hitting some hardware that we've left in a different state
to Windows.
Why are you making up these completely invalid arguments?
On Fri, Apr 04, 2014 at 09:09:32AM -0700, Linus Torvalds wrote:
On Fri, Apr 4, 2014 at 8:45 AM, Matthew Garrett mj...@srcf.ucam.org wrote:
Which is almost certainly because the other reboot methods are trapping
into SMI and hitting some hardware that we've left in a different state
to
On 04/04/2014 08:45 AM, Matthew Garrett wrote:
Windows hits the keyboard controller and then tries the ACPI vector. It
then sleeps for a short period, then tries the keyboard controller again
and the ACPI vector again.
So do you think we should move the KBC upward in our priority list?
That's not what you said a few posts ago.
On April 4, 2014 9:32:58 AM PDT, Matthew Garrett mj...@srcf.ucam.org wrote:
Windows does ACPI first, so no. And the Dells were broken even before
we moved ACPI up the list.
--
Sent from my mobile phone. Please pardon brevity and lack of formatting.
--
* Matthew Garrett mj...@srcf.ucam.org wrote:
On Fri, Apr 04, 2014 at 08:13:48AM -0700, H. Peter Anvin wrote:
On 04/04/2014 08:12 AM, Matthew Garrett wrote:
On Fri, Apr 04, 2014 at 09:27:48AM +0800, Li, Aubrey wrote:
The current situation is,
- we have one(do we know more?)
The comment header is bogus... it describes what we do, not what Windows does.
On April 4, 2014 10:34:31 AM PDT, Ingo Molnar mi...@kernel.org wrote:
* Matthew Garrett mj...@srcf.ucam.org wrote:
On Fri, Apr 04, 2014 at 08:13:48AM -0700, H. Peter Anvin wrote:
On 04/04/2014 08:12 AM, Matthew
* H. Peter Anvin h...@zytor.com wrote:
On April 4, 2014 9:32:58 AM PDT, Matthew Garrett mj...@srcf.ucam.org wrote:
Windows does ACPI first, so no. And the Dells were broken even
before we moved ACPI up the list.
That's not what you said a few posts ago.
Exactly, the claim ws:
* H. Peter Anvin h...@zytor.com wrote:
The comment header is bogus... it describes what we do, not what
Windows does.
That comment certainly pretends to describe Windows behavior and then
it goes to outline the differences in Linux behavior:
/*
* Windows compatible x86 hardware expects
On Fri, Apr 04, 2014 at 07:44:37PM +0200, Ingo Molnar wrote:
Before any other change is done beyond the revert of this latest
broken commit.
The commit in question was the one that added the misleading text to the
comment. I'm sorry, I should have caught that.
--
Matthew Garrett |
On Fri, Apr 4, 2014 at 9:21 AM, Matthew Garrett mj...@srcf.ucam.org wrote:
Because Windows doesn't use CF9 but machines reboot anyway. That
shouldn't be a controversial point of view.
No, that's not a controversial view.
But it's not the case for us, and I haven't seen a patch to make us
work
On Fri, Apr 4, 2014 at 9:31 AM, H. Peter Anvin h...@zytor.com wrote:
On 04/04/2014 08:45 AM, Matthew Garrett wrote:
Windows hits the keyboard controller and then tries the ACPI vector. It
then sleeps for a short period, then tries the keyboard controller again
and the ACPI vector again.
So
On 2014/4/4 10:16, Steven Rostedt wrote:
> On Fri, 04 Apr 2014 07:52:53 +0800
> "Li, Aubrey" wrote:
>
>> On 2014/4/4 7:40, Steven Rostedt wrote:
>>> On Fri, 04 Apr 2014 07:23:32 +0800
>>> "Li, Aubrey" wrote:
>>>
Can you please send the dmi table out?
>>>
>>> I already did as a gz
On Fri, 04 Apr 2014 07:52:53 +0800
"Li, Aubrey" wrote:
> On 2014/4/4 7:40, Steven Rostedt wrote:
> > On Fri, 04 Apr 2014 07:23:32 +0800
> > "Li, Aubrey" wrote:
> >
> >> Can you please send the dmi table out?
> >
> > I already did as a gz attachment to H. Peter. You were on the Cc, did
> > you
Keep in mind we already tried CF9 in the default flow and it broke things. I'm
willing to wait for reports about production machines, though, but I fully
expect them.
On April 3, 2014 6:27:48 PM PDT, "Li, Aubrey" wrote:
>On 2014/4/4 8:12, H. Peter Anvin wrote:
>> On 04/03/2014 04:52 PM, Li,
On 2014/4/4 8:12, H. Peter Anvin wrote:
> On 04/03/2014 04:52 PM, Li, Aubrey wrote:
>> On 2014/4/4 7:40, Steven Rostedt wrote:
>>> On Fri, 04 Apr 2014 07:23:32 +0800
>>> "Li, Aubrey" wrote:
>>>
Can you please send the dmi table out?
>>>
>>> I already did as a gz attachment to H. Peter. You
On 04/03/2014 04:52 PM, Li, Aubrey wrote:
> On 2014/4/4 7:40, Steven Rostedt wrote:
>> On Fri, 04 Apr 2014 07:23:32 +0800
>> "Li, Aubrey" wrote:
>>
>>> Can you please send the dmi table out?
>>
>> I already did as a gz attachment to H. Peter. You were on the Cc, did
>> you not receive it?
>>
>
On 2014/4/4 7:40, Steven Rostedt wrote:
> On Fri, 04 Apr 2014 07:23:32 +0800
> "Li, Aubrey" wrote:
>
>> Can you please send the dmi table out?
>
> I already did as a gz attachment to H. Peter. You were on the Cc, did
> you not receive it?
>
Oh, I got it. This is a Preproduction machine.
When
On Fri, 04 Apr 2014 07:23:32 +0800
"Li, Aubrey" wrote:
> Can you please send the dmi table out?
I already did as a gz attachment to H. Peter. You were on the Cc, did
you not receive it?
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
On 2014/4/4 0:13, Steven Rostedt wrote:
> On Thu, 03 Apr 2014 08:58:14 -0700
> "H. Peter Anvin" wrote:
>
>> On 04/03/2014 08:39 AM, Steven Rostedt wrote:
>>>
>>> Hmm, I didn't see this email. Note, this box is an old development box
>>> that Intel sent me years ago.
>>>
>>
>> Preproduction
On Thu, 03 Apr 2014 08:58:14 -0700
"H. Peter Anvin" wrote:
> On 04/03/2014 08:39 AM, Steven Rostedt wrote:
> >
> > Hmm, I didn't see this email. Note, this box is an old development box
> > that Intel sent me years ago.
> >
>
> Preproduction system?
>
Could be. Honestly, I don't remember. I
On 04/03/2014 08:39 AM, Steven Rostedt wrote:
>
> Hmm, I didn't see this email. Note, this box is an old development box
> that Intel sent me years ago.
>
Preproduction system?
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Thu, 03 Apr 2014 08:21:55 -0700
"H. Peter Anvin" wrote:
> On 04/03/2014 08:20 AM, H. Peter Anvin wrote:
> >
> > Also, can you send the dmidecode from your system? Is it a Dell?
Hmm, I didn't see this email. Note, this box is an old development box
that Intel sent me years ago.
> >
>
>
Rechecked my answers.
On Thu, 3 Apr 2014 10:47:21 -0400
Steven Rostedt wrote:
> On Thu, 03 Apr 2014 07:10:47 -0700
> "H. Peter Anvin" wrote:
>
> > Could you tell which of these modes work on your box:
> >
> > reboot=t
>
> I already stated that 't' works.
Yes it works.
>
> > reboot=k
>
On 04/03/2014 08:20 AM, H. Peter Anvin wrote:
>
> Also, can you send the dmidecode from your system? Is it a Dell?
>
(And I assume you're booting BIOS, not EFI.)
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On 04/03/2014 08:17 AM, Steven Rostedt wrote:
> On Thu, 3 Apr 2014 10:47:21 -0400
> Steven Rostedt wrote:
>
>> On Thu, 03 Apr 2014 07:10:47 -0700
>
>> Passed
>>
>>> reboot=a
>
> After getting Matthew's email, I tried this again and it failed to
> boot. Let me rerun through the list again and
On Thu, 3 Apr 2014 10:47:21 -0400
Steven Rostedt wrote:
> On Thu, 03 Apr 2014 07:10:47 -0700
> Passed
>
> > reboot=a
After getting Matthew's email, I tried this again and it failed to
boot. Let me rerun through the list again and I'll report back if
things have changed.
Changing options,
On Thu, 3 Apr 2014 15:50:22 +0100
Matthew Garrett wrote:
> On Thu, Apr 03, 2014 at 10:47:21AM -0400, Steven Rostedt wrote:
> > > reboot=a
> >
> > Passed
>
> Huh. We should be trying the acpi method twice before we try PCI at all,
> unless something's gone very wrong.
>
Bah, after getting
On Thu, Apr 03, 2014 at 10:47:21AM -0400, Steven Rostedt wrote:
> > reboot=a
>
> Passed
Huh. We should be trying the acpi method twice before we try PCI at all,
unless something's gone very wrong.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line
On Thu, 03 Apr 2014 07:10:47 -0700
"H. Peter Anvin" wrote:
> Could you tell which of these modes work on your box:
>
> reboot=t
I already stated that 't' works.
> reboot=k
Fails
> reboot=b (BIOS only)
Passed
> reboot=a
Passed
> reboot=e (EFI only)
Fails
> reboot=p
Fails
--
On 04/03/2014 06:41 AM, Steven Rostedt wrote:
> On Thu, 03 Apr 2014 14:30:50 +0800
> "Li, Aubrey" wrote:
>
>
>> May I know if "reboot=t" make any difference on your system with the change?
>
> Is this the future fix? Or do you have patches for me to test. I'll be
> happy to test any patches
On Thu, Apr 03, 2014 at 09:41:55AM -0400, Steven Rostedt wrote:
> On Thu, 03 Apr 2014 14:30:50 +0800
> "Li, Aubrey" wrote:
>
>
> > May I know if "reboot=t" make any difference on your system with the change?
>
> Is this the future fix? Or do you have patches for me to test. I'll be
> happy to
On Thu, 03 Apr 2014 14:30:50 +0800
"Li, Aubrey" wrote:
> May I know if "reboot=t" make any difference on your system with the change?
Is this the future fix? Or do you have patches for me to test. I'll be
happy to test any patches you have on this box. If you need to know
anything about this
On Thu, 03 Apr 2014 14:30:50 +0800
"Li, Aubrey" wrote:
> May I know if "reboot=t" make any difference on your system with the change?
It appears it does. Yes, it boots with "reboot=t" with the patches
applied, and does not reboot without it.
-- Steve
--
To unsubscribe from this list: send the
> From: Steven Rostedt [mailto:rost...@goodmis.org]
> Sent: Thursday, April 03, 2014 2:14 PM
> To: Linus Torvalds; LKML
> Cc: Ingo Molnar; H. Peter Anvin; Thomas Gleixner; Li, Aubrey; Matthew Garrett
> Subject: [BUG] x86: reboot doesn't reboot
>
> I noticed that one of my test
I noticed that one of my test boxes no longer does a reboot with the
latest kernel. It goes down and shows:
[ 51.589896] reboot: Restarting system
[ 51.593567] reboot: machine restart
And the system sounds like it turns off (the fans stop), but then I
just sit there and wait, and wait and
On Thu, 03 Apr 2014 14:30:50 +0800
Li, Aubrey aubrey...@linux.intel.com wrote:
May I know if reboot=t make any difference on your system with the change?
Is this the future fix? Or do you have patches for me to test. I'll be
happy to test any patches you have on this box. If you need to know
On Thu, Apr 03, 2014 at 09:41:55AM -0400, Steven Rostedt wrote:
On Thu, 03 Apr 2014 14:30:50 +0800
Li, Aubrey aubrey...@linux.intel.com wrote:
May I know if reboot=t make any difference on your system with the change?
Is this the future fix? Or do you have patches for me to test. I'll
On 04/03/2014 06:41 AM, Steven Rostedt wrote:
On Thu, 03 Apr 2014 14:30:50 +0800
Li, Aubrey aubrey...@linux.intel.com wrote:
May I know if reboot=t make any difference on your system with the change?
Is this the future fix? Or do you have patches for me to test. I'll be
happy to test
On Thu, 03 Apr 2014 07:10:47 -0700
H. Peter Anvin h...@zytor.com wrote:
Could you tell which of these modes work on your box:
reboot=t
I already stated that 't' works.
reboot=k
Fails
reboot=b (BIOS only)
Passed
reboot=a
Passed
reboot=e (EFI only)
Fails
reboot=p
Fails
On Thu, Apr 03, 2014 at 10:47:21AM -0400, Steven Rostedt wrote:
reboot=a
Passed
Huh. We should be trying the acpi method twice before we try PCI at all,
unless something's gone very wrong.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe
On Thu, 3 Apr 2014 15:50:22 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
On Thu, Apr 03, 2014 at 10:47:21AM -0400, Steven Rostedt wrote:
reboot=a
Passed
Huh. We should be trying the acpi method twice before we try PCI at all,
unless something's gone very wrong.
Bah, after
On Thu, 3 Apr 2014 10:47:21 -0400
Steven Rostedt rost...@goodmis.org wrote:
On Thu, 03 Apr 2014 07:10:47 -0700
Passed
reboot=a
After getting Matthew's email, I tried this again and it failed to
boot. Let me rerun through the list again and I'll report back if
things have changed.
On 04/03/2014 08:17 AM, Steven Rostedt wrote:
On Thu, 3 Apr 2014 10:47:21 -0400
Steven Rostedt rost...@goodmis.org wrote:
On Thu, 03 Apr 2014 07:10:47 -0700
Passed
reboot=a
After getting Matthew's email, I tried this again and it failed to
boot. Let me rerun through the list again
On 04/03/2014 08:20 AM, H. Peter Anvin wrote:
Also, can you send the dmidecode from your system? Is it a Dell?
(And I assume you're booting BIOS, not EFI.)
-hpa
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
Rechecked my answers.
On Thu, 3 Apr 2014 10:47:21 -0400
Steven Rostedt rost...@goodmis.org wrote:
On Thu, 03 Apr 2014 07:10:47 -0700
H. Peter Anvin h...@zytor.com wrote:
Could you tell which of these modes work on your box:
reboot=t
I already stated that 't' works.
Yes it works.
On Thu, 03 Apr 2014 08:21:55 -0700
H. Peter Anvin h...@zytor.com wrote:
On 04/03/2014 08:20 AM, H. Peter Anvin wrote:
Also, can you send the dmidecode from your system? Is it a Dell?
Hmm, I didn't see this email. Note, this box is an old development box
that Intel sent me years ago.
On 04/03/2014 08:39 AM, Steven Rostedt wrote:
Hmm, I didn't see this email. Note, this box is an old development box
that Intel sent me years ago.
Preproduction system?
-hpa
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
On Thu, 03 Apr 2014 08:58:14 -0700
H. Peter Anvin h...@zytor.com wrote:
On 04/03/2014 08:39 AM, Steven Rostedt wrote:
Hmm, I didn't see this email. Note, this box is an old development box
that Intel sent me years ago.
Preproduction system?
Could be. Honestly, I don't remember. I
On 2014/4/4 0:13, Steven Rostedt wrote:
On Thu, 03 Apr 2014 08:58:14 -0700
H. Peter Anvin h...@zytor.com wrote:
On 04/03/2014 08:39 AM, Steven Rostedt wrote:
Hmm, I didn't see this email. Note, this box is an old development box
that Intel sent me years ago.
Preproduction system?
On Fri, 04 Apr 2014 07:23:32 +0800
Li, Aubrey aubrey...@linux.intel.com wrote:
Can you please send the dmi table out?
I already did as a gz attachment to H. Peter. You were on the Cc, did
you not receive it?
-- Steve
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
On 2014/4/4 7:40, Steven Rostedt wrote:
On Fri, 04 Apr 2014 07:23:32 +0800
Li, Aubrey aubrey...@linux.intel.com wrote:
Can you please send the dmi table out?
I already did as a gz attachment to H. Peter. You were on the Cc, did
you not receive it?
Oh, I got it. This is a Preproduction
On 04/03/2014 04:52 PM, Li, Aubrey wrote:
On 2014/4/4 7:40, Steven Rostedt wrote:
On Fri, 04 Apr 2014 07:23:32 +0800
Li, Aubrey aubrey...@linux.intel.com wrote:
Can you please send the dmi table out?
I already did as a gz attachment to H. Peter. You were on the Cc, did
you not receive it?
On 2014/4/4 8:12, H. Peter Anvin wrote:
On 04/03/2014 04:52 PM, Li, Aubrey wrote:
On 2014/4/4 7:40, Steven Rostedt wrote:
On Fri, 04 Apr 2014 07:23:32 +0800
Li, Aubrey aubrey...@linux.intel.com wrote:
Can you please send the dmi table out?
I already did as a gz attachment to H. Peter. You
Keep in mind we already tried CF9 in the default flow and it broke things. I'm
willing to wait for reports about production machines, though, but I fully
expect them.
On April 3, 2014 6:27:48 PM PDT, Li, Aubrey aubrey...@linux.intel.com wrote:
On 2014/4/4 8:12, H. Peter Anvin wrote:
On
On Fri, 04 Apr 2014 07:52:53 +0800
Li, Aubrey aubrey...@linux.intel.com wrote:
On 2014/4/4 7:40, Steven Rostedt wrote:
On Fri, 04 Apr 2014 07:23:32 +0800
Li, Aubrey aubrey...@linux.intel.com wrote:
Can you please send the dmi table out?
I already did as a gz attachment to H. Peter.
On 2014/4/4 10:16, Steven Rostedt wrote:
On Fri, 04 Apr 2014 07:52:53 +0800
Li, Aubrey aubrey...@linux.intel.com wrote:
On 2014/4/4 7:40, Steven Rostedt wrote:
On Fri, 04 Apr 2014 07:23:32 +0800
Li, Aubrey aubrey...@linux.intel.com wrote:
Can you please send the dmi table out?
I already
I noticed that one of my test boxes no longer does a reboot with the
latest kernel. It goes down and shows:
[ 51.589896] reboot: Restarting system
[ 51.593567] reboot: machine restart
And the system sounds like it turns off (the fans stop), but then I
just sit there and wait, and wait and
From: Steven Rostedt [mailto:rost...@goodmis.org]
Sent: Thursday, April 03, 2014 2:14 PM
To: Linus Torvalds; LKML
Cc: Ingo Molnar; H. Peter Anvin; Thomas Gleixner; Li, Aubrey; Matthew Garrett
Subject: [BUG] x86: reboot doesn't reboot
I noticed that one of my test boxes no longer does
On Thu, 03 Apr 2014 14:30:50 +0800
Li, Aubrey aubrey...@linux.intel.com wrote:
May I know if reboot=t make any difference on your system with the change?
It appears it does. Yes, it boots with reboot=t with the patches
applied, and does not reboot without it.
-- Steve
--
To unsubscribe from
94 matches
Mail list logo
