avid Laight
CC: Arnd Bergmann
CC: Karsten Keil
CC: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Peter Hurley
---
drivers/isdn/i4l/isdn_tty.c | 2 +-
drivers/tty/hvc/hvc_console.c | 2 +-
drivers/tty/hvc/hvcs.c| 2 +-
drivers/tty/tty_port.c| 11 ++-
incl
This reverts commit 2fa645cb2703d9b3786d850db815414dfeefa51d.
The assumption that at least 1 preferred console will be registered
when the stdout-path property is set is invalid, which can result
in _no_ consoles.
Signed-off-by: Peter Hurley
---
drivers/of/base.c | 4 +---
1 file changed, 1
On 03/17/2015 04:16 PM, Pranith Kumar wrote:
> On Tue, Mar 17, 2015 at 4:13 PM, Peter Hurley
> wrote:
>> On 03/17/2015 04:07 PM, Pranith Kumar wrote:
>>> On Tue, Mar 17, 2015 at 4:03 PM, Peter Hurley
>>> wrote:
>>>>
>>>> Can you send
On 03/17/2015 04:07 PM, Pranith Kumar wrote:
> On Tue, Mar 17, 2015 at 4:03 PM, Peter Hurley
> wrote:
>>
>> Can you send me a complete dmesg capture from a boot with
>> this commit reverted?
>>
>
> Here it is. Let me know if you want any boot options enabled
On 03/17/2015 02:33 AM, Pranith Kumar wrote:
> On Mon, Mar 16, 2015 at 11:18 PM, Peter Hurley
> wrote:
>> On 03/16/2015 11:12 PM, Pranith Kumar wrote:
>>> On Mon, Mar 16, 2015 at 10:58 PM, Peter Hurley
>>> wrote:
>>>>>> What is your init?
>
On 03/16/2015 11:12 PM, Pranith Kumar wrote:
> On Mon, Mar 16, 2015 at 10:58 PM, Peter Hurley
> wrote:
>>>> What is your init?
>>>
>>> I am using systemd from debian unstable.
>>
>> Do you have a stdout-path property defined in your dts to a serial
On 03/16/2015 10:02 PM, Pranith Kumar wrote:
> On Mon, Mar 16, 2015 at 7:22 PM, Michael Ellerman wrote:
>>
>> The log shows that init is being killed, that's what's causing the panic.
>>
>> The exitcode of init is 0x200, which due to the vagaries of UNIX is I think
>> an
>> "exit status" of 2 in
uot;hung" there but you just lost
>> output.
>>
>> Try booting with "keep_bootcon" ?
>
> I tried this and got to the same place as in the first mail:
> http://imgur.com/s1lH15g
>
> There is a kernel panic with the message printed. Any more suggestions
> to how to debug this?
git bisect.
Regards,
Peter Hurley
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On 06/17/2014 07:03 AM, David Laight wrote:
> From: Peter Hurley
> ...
>>> I don't understand the second half of the changelog, it doesn't seem
>>> to fit here: there deadlock that we are trying to avoid here happens
>>> when the *same* tty needs the l
used more problems than it
> solved, and Alpha pretty much proved that. The engineering advantages
> would have to be so overwhelmingly in favor for someone to want to walk
> down that road again.
Secondly, I replied:
On 09/09/2014 07:14 AM, Peter Hurley wrote:
> I thought the overri
hat's to be expected.
As Paul pointed out, a good first step would be for the Alpha community
to contribute byte and short versions of smp_load_acquire() and
smp_store_release() so that the rest of the kernel community can make
forward progress on more parallelism without Alpha-only limitation
On 09/10/2014 05:48 PM, James Bottomley wrote:
> On Tue, 2014-09-09 at 06:40 -0400, Peter Hurley wrote:
>> On 09/08/2014 10:56 PM, James Bottomley wrote:
>>> On Mon, 2014-09-08 at 19:30 -0400, Peter Hurley wrote:
>>>> On 09/08/2014 01:50 AM, James Bottomley wrote:
&g
On 09/08/2014 03:17 PM, One Thousand Gnomes wrote:
>>> I think the whole "removing Alpha EV5" support is basically bonkers. Just
>>> use set_bit in the tty layer. Alpha will continue to work as well as it
>>> always has done and you won't design out support for any future processor
>>> that turns o
On 09/08/2014 06:47 PM, Peter Hurley wrote:
> On 09/08/2014 01:59 PM, H. Peter Anvin wrote:
>> On 09/08/2014 10:52 AM, One Thousand Gnomes wrote:
>>> On Fri, 05 Sep 2014 08:41:52 -0700
>>> "H. Peter Anvin" wrote:
>>>
>>>> On 09/05/201
On 09/08/2014 10:56 PM, James Bottomley wrote:
> On Mon, 2014-09-08 at 19:30 -0400, Peter Hurley wrote:
>> On 09/08/2014 01:50 AM, James Bottomley wrote:
>>>> But additionally, even if gcc combines adjacent writes _that are part
>>>> of the program flow_ then I
On 09/08/2014 01:50 AM, James Bottomley wrote:
> On Sun, 2014-09-07 at 16:41 -0400, Peter Hurley wrote:
>> On 09/07/2014 03:04 PM, James Bottomley wrote:
>>> On Sun, 2014-09-07 at 09:21 -0700, Paul E. McKenney wrote:
>>>> On Sat, Sep 06, 2014 at 10:07:22PM -0700, J
On 09/08/2014 01:59 PM, H. Peter Anvin wrote:
> On 09/08/2014 10:52 AM, One Thousand Gnomes wrote:
>> On Fri, 05 Sep 2014 08:41:52 -0700
>> "H. Peter Anvin" wrote:
>>
>>> On 09/05/2014 08:31 AM, Peter Hurley wrote:
>>>>
>>>>
On 09/07/2014 03:04 PM, James Bottomley wrote:
> On Sun, 2014-09-07 at 09:21 -0700, Paul E. McKenney wrote:
>> On Sat, Sep 06, 2014 at 10:07:22PM -0700, James Bottomley wrote:
>>> On Thu, 2014-09-04 at 21:06 -0700, Paul E. McKenney wrote:
>>>> On Thu, Sep 04, 2014 at
On 09/05/2014 04:39 PM, Michael Cree wrote:
> On Fri, Sep 05, 2014 at 04:14:48PM -0400, Peter Hurley wrote:
>> Second, in the body of the document:
>>
>> "The Linux kernel no longer supports pre-EV56 Alpha CPUs, because these
>> older CPUs _do not provide_ atomic
On 09/05/2014 03:38 PM, Marc Gauthier wrote:
> Paul E. McKenney wrote:
>> On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
>>> On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
>>>> This commit documents the fact that it is not safe to use bitfiel
ort? I'm all for removing that, but I need to see the patch merged
> before we can do this.
I'm working on that but Alpha's Kconfig is not quite straightforward.
... and I'm wondering if I should _remove_ pre-EV56 configurations or
move the default choice and produce a warning
On 09/05/2014 03:05 PM, Paul E. McKenney wrote:
> On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
>> On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
[cut]
>>>
>>>
>>>
On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
> On Fri, Sep 05, 2014 at 08:16:48PM +1200, Michael Cree wrote:
>> On Thu, Sep 04, 2014 at 07:08:48PM -0700, H. Peter Anvin wrote:
>>> On 09/04/2014 05:59 PM, Peter Hurley wrote:
>>>> I have no idea how prevalent t
On 09/05/2014 08:37 AM, David Laight wrote:
> From: Peter Hurley
>> On 09/05/2014 04:30 AM, David Laight wrote:
>>> I've seen gcc generate 32bit accesses for 16bit structure members on arm.
>>> It does this because of the more limited range of the offsets for t
On 09/04/2014 10:08 PM, H. Peter Anvin wrote:
> On 09/04/2014 05:59 PM, Peter Hurley wrote:
>> I have no idea how prevalent the ev56 is compared to the ev5.
>> Still we're talking about a chip that came out in 1996.
>
> Ah yes, I stand corrected. According to Wikipedia
for allmodconfig and a 4.8 cross-compiler.]
Maybe the test doesn't generate enough register pressure on the compiler?
Regards,
Peter Hurley
#define ARRAY_SIZE(x) (sizeof(x)/sizeof((x)[0]))
struct x {
long unused[64];
short b[12];
int unused2[10];
short c;
}
di 1,ret0
4: 0f 5c 12 08 stb ret0,4(r26)
8: 34 1c 00 04 ldi 2,ret0
c: e8 40 c0 00 bv r0(rp)
10: 0f 5c 12 0a stb ret0,5(r26)
which appears to confirm that on parisc adjacent byte data
is safe from corruption by concurrent cpu updates; that is,
CPU 0 | CPU 1
[ +cc linux-alpha ]
Hi Paul,
On 09/04/2014 08:17 PM, Paul E. McKenney wrote:
> On Thu, Sep 04, 2014 at 03:16:03PM -0700, H. Peter Anvin wrote:
>> On 09/04/2014 12:42 PM, Peter Hurley wrote:
>>>
>>> Or we could give up on the Alpha.
>>>
>>
>> If Alp
t0,1
4: 08 00 30 38 stb t0,8(a0)
8: 01 80 fa 6b ret
which is ok.
I have no idea how prevalent the ev56 is compared to the ev5.
Still we're talking about a chip that came out in 1996.
I still hate split caches though.
Regards,
Peter Hurley
___
; as a single instruction so it is interrupt safe.
Or we could give up on the Alpha.
It's not just the non-atomic bytes; we could do away with the
read_barrier_depends() which hardly any code gets correctly anyway.
Regards,
Peter Hurley
___
L
On 09/04/2014 05:09 AM, Jakub Jelinek wrote:
> On Thu, Sep 04, 2014 at 10:57:40AM +0200, Mikael Pettersson wrote:
>> Benjamin Herrenschmidt writes:
>> > On Wed, 2014-09-03 at 18:51 -0400, Peter Hurley wrote:
>> >
>> > > Apologies for hijacking this thre
; ie., a specific spinlock will be claimed before updating or accessing
certain fields while a different spinlock will be claimed before updating or
accessing certain _adjacent_ fields.
What is necessary and sufficient to prevent accidental false-sharing?
The patch below was flagged as insuffici
On 07/13/2014 06:25 PM, Benjamin Herrenschmidt wrote:
On Sun, 2014-07-13 at 09:15 -0400, Peter Hurley wrote:
I'm not sure I understand your point here, Ben.
Suppose that two different spinlocks are used independently to
protect r-m-w access to adjacent data. In Oleg's exampl
write to freeze_stop from the
kt_1 thread?
Regards,
Peter Hurley
In your example, I don't see the point of the bitfield.
Cheers,
Ben.
On 07/12, Oleg Nesterov wrote:
Hello,
I am not sure I should ask here, but since Documentation/memory-barriers.txt
mentions load/store tearing perhaps
On 07/10/2014 07:09 PM, Greg Kroah-Hartman wrote:
On Mon, Jun 16, 2014 at 09:17:11AM -0400, Peter Hurley wrote:
tty_wait_until_sent_from_close() drops the tty lock while waiting
for the tty driver to finish sending previously accepted data (ie.,
data remaining in its write buffer and transmit
On 06/17/2014 07:32 AM, Peter Hurley wrote:
On 06/17/2014 07:03 AM, David Laight wrote:
From: Peter Hurley
...
I don't understand the second half of the changelog, it doesn't seem
to fit here: there deadlock that we are trying to avoid here happens
when the *same* tty needs t
On 06/17/2014 07:03 AM, David Laight wrote:
From: Peter Hurley
...
I don't understand the second half of the changelog, it doesn't seem
to fit here: there deadlock that we are trying to avoid here happens
when the *same* tty needs the lock to complete the function that
sends the pendi
On 06/17/2014 04:00 AM, Arnd Bergmann wrote:
On Monday 16 June 2014 09:17:11 Peter Hurley wrote:
tty_wait_until_sent_from_close() drops the tty lock while waiting
for the tty driver to finish sending previously accepted data (ie.,
data remaining in its write buffer and transmit fifo).
However
ttys.
Since commit 89c8d91e31f267703e365593f6bfebb9f6d2ad01,
'tty: localise the lock', dropping the tty lock has not been necessary.
CC: Karsten Keil
CC: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Peter Hurley
---
drivers/isdn/i4l/isdn_tty.c | 2 +-
drivers/tty/hvc/hvc_cons
39 matches
Mail list logo
