On 03/05/2013 10:43 PM, Jiri Slaby wrote:
> send a fix for this one).
Hmm, did it work before actually? Even though the change was
unintentional and undocumented, it fixed the sysrq handling as far as I
can tell.
--
js
suse labs
--
To unsubscribe from this list: send the line "unsubscribe linux-
On Tue, 2013-03-05 at 15:53 -0500, David Miller wrote:
> From: Peter Hurley
> Date: Tue, 05 Mar 2013 15:47:04 -0500
>
> > On Tue, 2013-03-05 at 15:03 -0500, David Miller wrote:
> >> From: Jiri Slaby
> >> Date: Tue, 05 Mar 2013 20:44:49 +0100
> >>
> >> > Hi, I must admit I don't understand. I no
On 03/05/2013 09:34 PM, David Miller wrote:
>> which via sunsab_console_setup()
>> invokes sunsab_startup() which requests the IRQ.
Of course I see now, I overlooked that invocation before.
> And let's be honest about the fact that it's very possible that you've
> overlooked many issues like this
From: Peter Hurley
Date: Tue, 05 Mar 2013 15:47:04 -0500
> On Tue, 2013-03-05 at 15:03 -0500, David Miller wrote:
>> From: Jiri Slaby
>> Date: Tue, 05 Mar 2013 20:44:49 +0100
>>
>> > Hi, I must admit I don't understand. I now checked both of them and they
>> > call uart_handle_sysrq_char uncond
On Tue, 2013-03-05 at 15:03 -0500, David Miller wrote:
> From: Jiri Slaby
> Date: Tue, 05 Mar 2013 20:44:49 +0100
>
> > Hi, I must admit I don't understand. I now checked both of them and they
> > call uart_handle_sysrq_char unconditionally, or?
>
> Nope, in the sunsab.c receive function, we use
From: David Miller
Date: Tue, 05 Mar 2013 15:33:58 -0500 (EST)
> From: Jiri Slaby
> Date: Tue, 05 Mar 2013 21:27:59 +0100
>
>> On 03/05/2013 09:03 PM, David Miller wrote:
>>> From: Jiri Slaby
>>> Date: Tue, 05 Mar 2013 20:44:49 +0100
>>>
Hi, I must admit I don't understand. I now checked
From: Jiri Slaby
Date: Tue, 05 Mar 2013 21:27:59 +0100
> On 03/05/2013 09:03 PM, David Miller wrote:
>> From: Jiri Slaby
>> Date: Tue, 05 Mar 2013 20:44:49 +0100
>>
>>> Hi, I must admit I don't understand. I now checked both of them and they
>>> call uart_handle_sysrq_char unconditionally, or?
On 03/05/2013 09:03 PM, David Miller wrote:
> From: Jiri Slaby
> Date: Tue, 05 Mar 2013 20:44:49 +0100
>
>> Hi, I must admit I don't understand. I now checked both of them and they
>> call uart_handle_sysrq_char unconditionally, or?
>
> Nope, in the sunsab.c receive function, we used to handle t
From: Jiri Slaby
Date: Tue, 05 Mar 2013 20:44:49 +0100
> Hi, I must admit I don't understand. I now checked both of them and they
> call uart_handle_sysrq_char unconditionally, or?
Nope, in the sunsab.c receive function, we used to handle the SYSRQ
stuff before break checking when TTY is NULL, n
On 03/05/2013 08:39 PM, David Miller wrote:
> From: Jiri Slaby
> Date: Tue, 05 Mar 2013 12:01:06 +0100
>
>> I left that "if (port->start == NULL)" in sunhv in place because it
>> behaves completely differently. It checks port->start on all paths prior
>> dereferencing it. And it does not stop int
From: Jiri Slaby
Date: Tue, 05 Mar 2013 12:01:06 +0100
> I left that "if (port->start == NULL)" in sunhv in place because it
> behaves completely differently. It checks port->start on all paths prior
> dereferencing it. And it does not stop interrupts on ->shutdown.
But this code really does car
On 03/01/2013 11:00 PM, David Miller wrote:
> From: David Miller
> Date: Fri, 01 Mar 2013 16:47:11 -0500 (EST)
>
>>
>> I'm getting these non-stop right when the hypervisor console registers
>> on sparc64, and the machine won't boot up properly. This is with
>> Linus's current tree.
>
> As a qui
From: Al Viro
Date: Sat, 2 Mar 2013 05:23:30 +
> On Sat, Mar 02, 2013 at 03:49:35PM +1100, Stephen Rothwell wrote:
>> On Fri, 01 Mar 2013 17:10:08 -0500 (EST) David Miller
>> wrote:
>
>> > Ok, next I'm hitting some regression in Al Viro's signal changes when
>> > userland
>> > starts up.
On Sat, Mar 02, 2013 at 03:49:35PM +1100, Stephen Rothwell wrote:
> On Fri, 01 Mar 2013 17:10:08 -0500 (EST) David Miller
> wrote:
> > Ok, next I'm hitting some regression in Al Viro's signal changes when
> > userland
> > starts up. :-)
>
> If only we had some way of testing this stuff before
On Fri, 01 Mar 2013 17:10:08 -0500 (EST) David Miller
wrote:
>
> From: Greg KH
> Date: Fri, 1 Mar 2013 13:56:09 -0800
>
> > On Fri, Mar 01, 2013 at 04:47:11PM -0500, David Miller wrote:
> >>
> >> I'm getting these non-stop right when the hypervisor console registers
> >> on sparc64, and the ma
From: Greg KH
Date: Fri, 1 Mar 2013 13:56:09 -0800
> On Fri, Mar 01, 2013 at 04:47:11PM -0500, David Miller wrote:
>>
>> I'm getting these non-stop right when the hypervisor console registers
>> on sparc64, and the machine won't boot up properly. This is with
>> Linus's current tree.
>>
>> [51
From: David Miller
Date: Fri, 01 Mar 2013 16:47:11 -0500 (EST)
>
> I'm getting these non-stop right when the hypervisor console registers
> on sparc64, and the machine won't boot up properly. This is with
> Linus's current tree.
As a quick addendum I'm looking at all of these tty_insert_flip_c
On Fri, Mar 01, 2013 at 04:47:11PM -0500, David Miller wrote:
>
> I'm getting these non-stop right when the hypervisor console registers
> on sparc64, and the machine won't boot up properly. This is with
> Linus's current tree.
>
> [511865.556835] console [ttyHV0] enabled
> [511865.564555] -
I'm getting these non-stop right when the hypervisor console registers
on sparc64, and the machine won't boot up properly. This is with
Linus's current tree.
[511865.556835] console [ttyHV0] enabled
[511865.564555] [ cut here ]
[511865.612410] WARNING: at drivers/tty/tty_
19 matches
Mail list logo
