> On 26. Jun 2020, at 18:13, David Laight wrote:
>
> From: Xin Long
>> Sent: 23 June 2020 11:14
It looks like a bug to me. Testing with this test app here, I can see
the INIT_ACK being sent with a bunch of ipv4 addresses in it and
that's unexpected for a v6only socket. As is, it's
From: Xin Long
> Sent: 23 June 2020 11:14
> > > It looks like a bug to me. Testing with this test app here, I can see
> > > the INIT_ACK being sent with a bunch of ipv4 addresses in it and
> > > that's unexpected for a v6only socket. As is, it's the server saying
> > > "I'm available at these other
> On 24. Jun 2020, at 09:25, Xin Long wrote:
>
> On Wed, Jun 24, 2020 at 5:48 AM Michael Tuexen
> wrote:
>>
>>> On 23. Jun 2020, at 23:31, Marcelo Ricardo Leitner
>>> wrote:
>>>
>>> On Tue, Jun 23, 2020 at 11:24:59PM +0200, Michael Tuexen wrote:
> On 23. Jun 2020, at 23:21, Marcelo Ricar
On Wed, Jun 24, 2020 at 5:48 AM Michael Tuexen
wrote:
>
> > On 23. Jun 2020, at 23:31, Marcelo Ricardo Leitner
> > wrote:
> >
> > On Tue, Jun 23, 2020 at 11:24:59PM +0200, Michael Tuexen wrote:
> >>> On 23. Jun 2020, at 23:21, Marcelo Ricardo Leitner
> >>> wrote:
> >>>
> >>> On Tue, Jun 23, 20
On Wed, Jun 24, 2020 at 12:00 AM Corey Minyard wrote:
>
> On Tue, Jun 23, 2020 at 11:40:21PM +0800, Xin Long wrote:
> > On Tue, Jun 23, 2020 at 9:29 PM Corey Minyard wrote:
> > >
> > > On Tue, Jun 23, 2020 at 06:13:30PM +0800, Xin Long wrote:
> > > > On Tue, Jun 23, 2020 at 2:34 AM Michael Tuexen
> On 23. Jun 2020, at 23:31, Marcelo Ricardo Leitner
> wrote:
>
> On Tue, Jun 23, 2020 at 11:24:59PM +0200, Michael Tuexen wrote:
>>> On 23. Jun 2020, at 23:21, Marcelo Ricardo Leitner
>>> wrote:
>>>
>>> On Tue, Jun 23, 2020 at 11:17:56AM -0500, Corey Minyard wrote:
On Tue, Jun 23, 2020
On Tue, Jun 23, 2020 at 11:24:59PM +0200, Michael Tuexen wrote:
> > On 23. Jun 2020, at 23:21, Marcelo Ricardo Leitner
> > wrote:
> >
> > On Tue, Jun 23, 2020 at 11:17:56AM -0500, Corey Minyard wrote:
> >> On Tue, Jun 23, 2020 at 01:17:28PM +, David Laight wrote:
> >>> From: Marcelo Ricardo
> On 23. Jun 2020, at 23:21, Marcelo Ricardo Leitner
> wrote:
>
> On Tue, Jun 23, 2020 at 11:17:56AM -0500, Corey Minyard wrote:
>> On Tue, Jun 23, 2020 at 01:17:28PM +, David Laight wrote:
>>> From: Marcelo Ricardo Leitner
Sent: 22 June 2020 19:33
On Mon, Jun 22, 2020 at 08:01:24P
On Tue, Jun 23, 2020 at 11:17:56AM -0500, Corey Minyard wrote:
> On Tue, Jun 23, 2020 at 01:17:28PM +, David Laight wrote:
> > From: Marcelo Ricardo Leitner
> > > Sent: 22 June 2020 19:33
> > > On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote:
> > > > > On 22. Jun 2020, at 18:57,
> On 23. Jun 2020, at 15:17, David Laight wrote:
>
> From: Marcelo Ricardo Leitner
>> Sent: 22 June 2020 19:33
>> On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote:
On 22. Jun 2020, at 18:57, Corey Minyard wrote:
On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wro
On Tue, Jun 23, 2020 at 01:17:28PM +, David Laight wrote:
> From: Marcelo Ricardo Leitner
> > Sent: 22 June 2020 19:33
> > On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote:
> > > > On 22. Jun 2020, at 18:57, Corey Minyard wrote:
> > > >
> > > > On Mon, Jun 22, 2020 at 08:01:23PM
On Tue, Jun 23, 2020 at 11:40:21PM +0800, Xin Long wrote:
> On Tue, Jun 23, 2020 at 9:29 PM Corey Minyard wrote:
> >
> > On Tue, Jun 23, 2020 at 06:13:30PM +0800, Xin Long wrote:
> > > On Tue, Jun 23, 2020 at 2:34 AM Michael Tuexen
> > > wrote:
> > > >
> > > > > On 22. Jun 2020, at 20:32, Marcelo
On Tue, Jun 23, 2020 at 9:29 PM Corey Minyard wrote:
>
> On Tue, Jun 23, 2020 at 06:13:30PM +0800, Xin Long wrote:
> > On Tue, Jun 23, 2020 at 2:34 AM Michael Tuexen
> > wrote:
> > >
> > > > On 22. Jun 2020, at 20:32, Marcelo Ricardo Leitner
> > > > wrote:
> > > >
> > > > On Mon, Jun 22, 2020 a
On Tue, Jun 23, 2020 at 06:13:30PM +0800, Xin Long wrote:
> On Tue, Jun 23, 2020 at 2:34 AM Michael Tuexen
> wrote:
> >
> > > On 22. Jun 2020, at 20:32, Marcelo Ricardo Leitner
> > > wrote:
> > >
> > > On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote:
> > >>> On 22. Jun 2020, at 18
From: Marcelo Ricardo Leitner
> Sent: 22 June 2020 19:33
> On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote:
> > > On 22. Jun 2020, at 18:57, Corey Minyard wrote:
> > >
> > > On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote:
> > >> On Sun, Jun 21, 2020 at 11:56 PM Corey Minya
On Tue, Jun 23, 2020 at 2:34 AM Michael Tuexen
wrote:
>
> > On 22. Jun 2020, at 20:32, Marcelo Ricardo Leitner
> > wrote:
> >
> > On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote:
> >>> On 22. Jun 2020, at 18:57, Corey Minyard wrote:
> >>>
> >>> On Mon, Jun 22, 2020 at 08:01:23PM
> On 22. Jun 2020, at 20:32, Marcelo Ricardo Leitner
> wrote:
>
> On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote:
>>> On 22. Jun 2020, at 18:57, Corey Minyard wrote:
>>>
>>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote:
On Sun, Jun 21, 2020 at 11:56 PM Corey Mi
On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote:
> > On 22. Jun 2020, at 18:57, Corey Minyard wrote:
> >
> > On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote:
> >> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote:
> >>>
> >>> I've stumbled upon a strange problem with
> On 22. Jun 2020, at 18:57, Corey Minyard wrote:
>
> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote:
>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote:
>>>
>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an
>>> sctp listening socket on :: and set the I
On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote:
> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote:
> >
> > I've stumbled upon a strange problem with SCTP and IPv6. If I create an
> > sctp listening socket on :: and set the IPV6_V6ONLY socket option on it,
> > then I make a connecti
> On 22. Jun 2020, at 14:01, Xin Long wrote:
>
> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote:
>>
>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an
>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it,
>> then I make a connection to it
On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote:
>
> I've stumbled upon a strange problem with SCTP and IPv6. If I create an
> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it,
> then I make a connection to it using ::1, the connection will drop after
> 2.5 seconds wit
On Wed, 12 Jun 2019, Rafael J. Wysocki wrote:
> > > hid-logitech-dj is not loaded after a fresh boot, so I need to modprobe
> > > it manually and that
> > > appears to be blocking (apparently indefinitely) until terminated with
> > > ^C. But then it turns
> > > out that hid-logitech-dj is there
On Wednesday, June 12, 2019 10:31:45 AM CEST Jiri Kosina wrote:
> On Wed, 12 Jun 2019, Rafael J. Wysocki wrote:
>
> > It kind of helps, but there is a catch.
> >
> > hid-logitech-dj is not loaded after a fresh boot, so I need to modprobe it
> > manually and that
> > appears to be blocking (appar
On Wed, 12 Jun 2019, Rafael J. Wysocki wrote:
> It kind of helps, but there is a catch.
>
> hid-logitech-dj is not loaded after a fresh boot, so I need to modprobe it
> manually and that
> appears to be blocking (apparently indefinitely) until terminated with ^C.
> But then it turns
> out that
On Wednesday, June 12, 2019 12:02:21 AM CEST Jiri Kosina wrote:
> On Tue, 11 Jun 2019, Rafael J. Wysocki wrote:
>
> > I noticed that the cordless mouse used by me with one of the machines here
> > stopped to work in 5.2-rc (up to and including the -rc4).
> >
> > Bisection turned up commit 74808f9
On Tue, 11 Jun 2019, Rafael J. Wysocki wrote:
> I noticed that the cordless mouse used by me with one of the machines here
> stopped to work in 5.2-rc (up to and including the -rc4).
>
> Bisection turned up commit 74808f9115ce ("HID: logitech-dj: add support for
> non
> unifying receivers").
>
On Thu, 02 May 2019, Deepa Dinamani wrote:
Reported-by: Omar Kilani
Do we actually know if this was the issue Omar was hitting?
Thanks,
Davidlohr
Deepa Dinamani wrote:
> Eric,
> Can you please help test this?
Nope, that was _really_ badly whitespace-damaged.
(C'mon, it's not like you're new to this)
Eric,
Can you please help test this?
If this solves your problem, I can post the fix.
Thanks,
- Deepa
-8<---
Subject: [PATCH] signal: Adjust error codes according to restore_user_sigmask()
For all the syscalls that receive a sigmask from the userland,
the user sigmask is to be in eff
On Wed, May 1, 2019 at 1:48 PM Eric Wong wrote:
>
> Deepa Dinamani wrote:
> > So here is my analysis:
>
>
>
> > So the 854a6ed56839a40f6 seems to be better than the original code in
> > that it detects the signal.
>
> OTOH, does matter to anybody that a signal is detected slightly
> sooner than
Deepa Dinamani wrote:
> So here is my analysis:
> So the 854a6ed56839a40f6 seems to be better than the original code in
> that it detects the signal.
OTOH, does matter to anybody that a signal is detected slightly
sooner than it would've been, otherwise?
> But, the problem is that it doesn't
Thanks for trying the fix.
So here is my analysis:
Let's start with epoll_pwait:
ep_poll() is what checks for signal_pending() and is responsible for
setting errno to -EINTR when there is a signal.
So if a signal is received after ep_poll(), it is never noticed by the
syscall during execution.
Eric Wong wrote:
> (didn't test AIO, but everything else seems good)
"seems" != "is"
Now that I understand the fix for epoll, the fs/select.c changes
would hit the same problem and not return -EINTR when it should.
I'll let you guys decide how to fix this, but there's definitely
a problem when
Eric Wong wrote:
> Deepa Dinamani wrote:
> > I'm not sure what the hang in the userspace is about. Is it because
> > the syscall did not return an error or the particular signal was
> > blocked etc.
>
> Uh, ok; that's less comforting.
Nevermind, I think I understand everything, now. epoll_pwai
Deepa Dinamani wrote:
> I was also not able to reproduce this.
> Arnd and I were talking about this today morning. Here is something
> Arnd noticed:
>
> If there was a signal after do_epoll_wait(), we never were not
> entering the if (err = -EINTR) at all before.
I'm not sure which `if' statemen
I was also not able to reproduce this.
Arnd and I were talking about this today morning. Here is something
Arnd noticed:
If there was a signal after do_epoll_wait(), we never were not
entering the if (err = -EINTR) at all before. But, now we do.
We could try with the below patch:
diff --git a/fs/
Davidlohr Bueso wrote:
> On Sun, 28 Apr 2019, Eric Wong wrote:
>
> > Just running one test won't trigger since it needs a busy
> > machine; but:
> >
> > make test/mgmt_auto_adjust.log
> > (and "rm make test/mgmt_auto_adjust.log" if you want to rerun)
>
> fyi no luck reproducing on both
On Sun, 28 Apr 2019, Eric Wong wrote:
Just running one test won't trigger since it needs a busy
machine; but:
make test/mgmt_auto_adjust.log
(and "rm make test/mgmt_auto_adjust.log" if you want to rerun)
fyi no luck reproducing on both either a large (280) or small (4 cpu)
mac
Deepa Dinamani wrote:
> I tried to replicate the failure on qemu.
> I do not see the failure with N=32.
> Does it work for N < 32?
Depends on number of cores you have; I have 4 cores, 8 threads
with HT; so I needed to have a lot of load on the machine to get
it to fail (it takes about 1 minute).
I tried to replicate the failure on qemu.
I do not see the failure with N=32.
Does it work for N < 32?
Does any other signal work?
Are there any other architectures that fail?
Could you help me figure out how to run just the one test that is failing?
-Deepa
Eric Wong wrote:
> Omar Kilani wrote:
> > Hi there,
> >
> > I’m still trying to piece together a reproducible test that triggers
> > this, but I wanted to post in case someone goes “hmmm... change X
> > might have done this”.
>
> Maybe Davidlohr knows, since he's responsible for most of the
> e
On Wed, 24 Apr 2019, Davidlohr Bueso wrote:
On Wed, 24 Apr 2019, Eric Wong wrote:
Omar Kilani wrote:
Hi there,
I???m still trying to piece together a reproducible test that triggers
this, but I wanted to post in case someone goes ???hmmm... change X
might have done this???.
Maybe Davidloh
On Wed, 24 Apr 2019, Eric Wong wrote:
Omar Kilani wrote:
Hi there,
I???m still trying to piece together a reproducible test that triggers
this, but I wanted to post in case someone goes ???hmmm... change X
might have done this???.
Maybe Davidlohr knows, since he's responsible for most of th
Omar Kilani wrote:
> Hi there,
>
> I’m still trying to piece together a reproducible test that triggers
> this, but I wanted to post in case someone goes “hmmm... change X
> might have done this”.
Maybe Davidlohr knows, since he's responsible for most of the
epoll changes in 5.0.
> Basically, s
* Steven Rostedt wrote:
> On Tue, 4 Dec 2018 09:15:06 +0100
> Ingo Molnar wrote:
>
> > * Masami Hiramatsu wrote:
> >
> > > I remember I have fixed this, and actually WE did it :-D
> > >
> > > https://lkml.org/lkml/2018/8/23/1203
> > >
> > > Ah, we hit a same bug...
> > >
> > > Ingo, coul
On Tue, 4 Dec 2018 09:15:06 +0100
Ingo Molnar wrote:
> * Masami Hiramatsu wrote:
>
> > I remember I have fixed this, and actually WE did it :-D
> >
> > https://lkml.org/lkml/2018/8/23/1203
> >
> > Ah, we hit a same bug...
> >
> > Ingo, could you pick the patch? Should I resend it?
>
> Ind
* Masami Hiramatsu wrote:
> I remember I have fixed this, and actually WE did it :-D
>
> https://lkml.org/lkml/2018/8/23/1203
>
> Ah, we hit a same bug...
>
> Ingo, could you pick the patch? Should I resend it?
Indeed: I just picked it up into tip:perf/urgent.
It's my bad: I missed the ori
On Tue, 4 Dec 2018 16:40:07 +0900
Masami Hiramatsu wrote:
> Hi Steve,
>
> On Mon, 3 Dec 2018 21:18:07 -0500
> Steven Rostedt wrote:
>
> > Hi Masami,
> >
> > I started testing some of my new code and the system got into a
> > strange state. Debugging further, I found the cause came from the
>
Hi Steve,
On Mon, 3 Dec 2018 21:18:07 -0500
Steven Rostedt wrote:
> Hi Masami,
>
> I started testing some of my new code and the system got into a
> strange state. Debugging further, I found the cause came from the
> kprobe tests. It became stranger to me that I could reproduce it with
> older
On 6/2/2017 9:43 AM, Michal Hocko wrote:
On Fri 02-06-17 09:20:54, Tom Lendacky wrote:
On 5/31/2017 11:04 AM, Michal Hocko wrote:
Hi Tom,
Hi Michal,
I have stumbled over the following construct in xgbe_map_rx_buffer
order = max_t(int, PAGE_ALLOC_COSTLY_ORDER - 1, 0);
which looks qui
On Fri 02-06-17 09:20:54, Tom Lendacky wrote:
> On 5/31/2017 11:04 AM, Michal Hocko wrote:
> >Hi Tom,
>
> Hi Michal,
>
> >I have stumbled over the following construct in xgbe_map_rx_buffer
> > order = max_t(int, PAGE_ALLOC_COSTLY_ORDER - 1, 0);
> >which looks quite suspicious. Why does it PAG
On 5/31/2017 11:04 AM, Michal Hocko wrote:
Hi Tom,
Hi Michal,
I have stumbled over the following construct in xgbe_map_rx_buffer
order = max_t(int, PAGE_ALLOC_COSTLY_ORDER - 1, 0);
which looks quite suspicious. Why does it PAGE_ALLOC_COSTLY_ORDER - 1?
And why do you depend on PAGE_ALL
On Mon, Aug 08, 2016 at 03:03:43PM +0200, Peter Zijlstra wrote:
> On Fri, Aug 05, 2016 at 12:23:20PM +0200, Jiri Olsa wrote:
> > On Fri, Aug 05, 2016 at 12:30:32PM +0300, Nikolay Borisov wrote:
> > >
> > >
> > > On 08/04/2016 06:29 PM, Jiri Olsa wrote:
> > > > On Tue, Jul 26, 2016 at 02:30:46PM +
On Fri, Aug 05, 2016 at 12:23:20PM +0200, Jiri Olsa wrote:
> On Fri, Aug 05, 2016 at 12:30:32PM +0300, Nikolay Borisov wrote:
> >
> >
> > On 08/04/2016 06:29 PM, Jiri Olsa wrote:
> > > On Tue, Jul 26, 2016 at 02:30:46PM +0300, Nikolay Borisov wrote:
> > [SNIP]
> > >
> > > sorry for late response
On Fri, Aug 05, 2016 at 12:30:32PM +0300, Nikolay Borisov wrote:
>
>
> On 08/04/2016 06:29 PM, Jiri Olsa wrote:
> > On Tue, Jul 26, 2016 at 02:30:46PM +0300, Nikolay Borisov wrote:
> [SNIP]
> >
> > sorry for late response..
> >
> > I checked on f22 kernel and it's missing the core2 PEBs fix:
>
On 08/04/2016 06:29 PM, Jiri Olsa wrote:
> On Tue, Jul 26, 2016 at 02:30:46PM +0300, Nikolay Borisov wrote:
[SNIP]
>
> sorry for late response..
>
> I checked on f22 kernel and it's missing the core2 PEBs fix:
> 1424a09a9e18 perf/x86: fix PEBS issues on Intel Atom/Core2
>
> which was introdu
On Tue, Jul 26, 2016 at 02:30:46PM +0300, Nikolay Borisov wrote:
>
>
> On 07/20/2016 05:38 PM, Jiri Olsa wrote:
> > On Wed, Jul 20, 2016 at 04:34:17PM +0200, Jiri Olsa wrote:
> >> On Wed, Jul 20, 2016 at 04:28:34PM +0300, Nikolay Borisov wrote:
> >>> Hello,
> >>>
> >>> Running perf version 4.4.14
On 07/20/2016 05:38 PM, Jiri Olsa wrote:
> On Wed, Jul 20, 2016 at 04:34:17PM +0200, Jiri Olsa wrote:
>> On Wed, Jul 20, 2016 at 04:28:34PM +0300, Nikolay Borisov wrote:
>>> Hello,
>>>
>>> Running perf version 4.4.14.g0cb188d (no modification to the PMU/perf
>>> code) I observed that "perf top" c
Hi,
After looking at this further we found that there is actually
a rate limit on 'rst' packets sent by OSX on a closed socket.
Its set to 250 per second and controlled via:
net.inet.icmp.icmplim. Increasing that limit resolves the
issue, but the default is apparently 250.
Thanks,
-Jason
On 07
On 07/20/2016 05:34 PM, Jiri Olsa wrote:
> On Wed, Jul 20, 2016 at 04:28:34PM +0300, Nikolay Borisov wrote:
>> Hello,
>>
>> Running perf version 4.4.14.g0cb188d (no modification to the PMU/perf
>> code) I observed that "perf top" counts no cycles and produces no
>> output. After a bit of head scr
On Wed, Jul 20, 2016 at 04:34:17PM +0200, Jiri Olsa wrote:
> On Wed, Jul 20, 2016 at 04:28:34PM +0300, Nikolay Borisov wrote:
> > Hello,
> >
> > Running perf version 4.4.14.g0cb188d (no modification to the PMU/perf
> > code) I observed that "perf top" counts no cycles and produces no
> > output. A
On Wed, Jul 20, 2016 at 04:28:34PM +0300, Nikolay Borisov wrote:
> Hello,
>
> Running perf version 4.4.14.g0cb188d (no modification to the PMU/perf
> code) I observed that "perf top" counts no cycles and produces no
> output. After a bit of head scratching and testing I figured that
> running "per
On 07/01/2016 02:16 PM, One Thousand Gnomes wrote:
>> yes, we do in fact see a POLLRDHUP from the FIN in this case and
>> read of zero, but we still have more data to write to the socket, and
>> b/c the RST is dropped here, the socket stays in TIME_WAIT until
>> things eventually time out...
>
>
> yes, we do in fact see a POLLRDHUP from the FIN in this case and
> read of zero, but we still have more data to write to the socket, and
> b/c the RST is dropped here, the socket stays in TIME_WAIT until
> things eventually time out...
After the FIN when you send/retransmit your next segment do
On 07/01/2016 01:08 PM, Rick Jones wrote:
> On 07/01/2016 08:10 AM, Jason Baron wrote:
>> I'm wondering if anybody else has run into this...
>>
>> On Mac OSX 10.11.5 (latest version), we have found that when tcp
>> connections are abruptly terminated (via ^C), a FIN is sent followed
>> by an RST pa
On 07/01/2016 08:10 AM, Jason Baron wrote:
I'm wondering if anybody else has run into this...
On Mac OSX 10.11.5 (latest version), we have found that when tcp
connections are abruptly terminated (via ^C), a FIN is sent followed
by an RST packet.
That just seems, well, silly. If the client app
> On Mac OSX 10.11.5 (latest version), we have found that when tcp
> connections are abruptly terminated (via ^C), a FIN is sent followed
> by an RST packet. The RST is sent with the same sequence number as the
> FIN, and thus dropped since the stack only accepts RST packets matching
> rcv_nxt (RFC
On Fri, Apr 29, 2016 at 9:36 PM, Rus wrote:
> Hi,
>
> After switching from 3.x to 4.x I'm observing strange filesystem (ext4
> used) slowdown just after fresh boot - it is 100% reproducible. The
> simple test just after boot at root fs first shows the good
> performance :
>
> dd if=/dev/zero of=/o
Hello,
On Sat, Dec 05, 2015 at 09:10:08AM +0800, Herbert Xu wrote:
> On Fri, Nov 27, 2015 at 04:23:54PM +0100, Philipp Hahn wrote:
> >
> > I observed a strange stall in a multi-threaded process (originally
> > OpenLDAP slapd), which stalls during a call to getaddrinfo() after
> > upgrading the ke
On Fri, Nov 27, 2015 at 04:23:54PM +0100, Philipp Hahn wrote:
>
> I observed a strange stall in a multi-threaded process (originally
> OpenLDAP slapd), which stalls during a call to getaddrinfo() after
> upgrading the kernel from 3.16.x to 4.1.12:
Can you try to see if the latest kernel still has
Le 02/09/2015 16:20, Joakim Tjernlund a écrit :
On Thu, 2015-08-27 at 15:58 +0200, leroy christophe wrote:
Hi,
Has anybody already used 'perf' tool on powerpc MPC83xx ?
I have been succesfully using perf on MPC8xx, but on MPC83xx I get
something strange.
perf record/report reports addresses
On Thu, 2015-08-27 at 15:58 +0200, leroy christophe wrote:
> Hi,
>
> Has anybody already used 'perf' tool on powerpc MPC83xx ?
>
> I have been succesfully using perf on MPC8xx, but on MPC83xx I get
> something strange.
>
> perf record/report reports addresses on user stack, as if it was mixing
Hi!
For all others, having problems w/ broken multicast:
See the solution here:
http://article.gmane.org/gmane.linux.kernel/1625590
Regards,
Andreas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo in
On Fri, 3 Jan 2014 15:27:19 +0100
Andreas Hartmann wrote:
[...]
> Now the problem:
>
> If the VM (=AP) runs e.g. Linux 3.4.x, all is working fine as expected.
> If the VM runs 3.12.x or even 3.10.x, the tunnel works fine a few minutes
> after creation. Afterwards it is broken.
>
> Broken mea
On Sat, 02 Nov 2013 07:33:21 +1100, Benjamin Herrenschmidt
wrote:
> On Fri, 2013-11-01 at 11:04 -0700, Grant Likely wrote:
>
> > There are two problems here. First, making the change moves all the DT
> > populated devices under the /sys/devices/platform tree, not just
> > platform devices.
>
>
On Sat, 2 Nov 2013 10:45:05 +1100, NeilBrown wrote:
> On Sat, 02 Nov 2013 10:10:25 +1100 Benjamin Herrenschmidt
> wrote:
>
> > On Fri, 2013-11-01 at 13:47 -0700, Greg Kroah-Hartman wrote:
> >
> > > > > On my device I seem to have some platform devices registered through
> > > > > device-tree, a
On Sat, Nov 02, 2013 at 10:45:05AM +1100, NeilBrown wrote:
> On Sat, 02 Nov 2013 10:10:25 +1100 Benjamin Herrenschmidt
> wrote:
>
> > On Fri, 2013-11-01 at 13:47 -0700, Greg Kroah-Hartman wrote:
> >
> > > > > On my device I seem to have some platform devices registered through
> > > > > device-t
On Sat, 2013-11-02 at 13:40 -0700, Greg Kroah-Hartman wrote:
> On Sun, Nov 03, 2013 at 07:22:10AM +1100, Benjamin Herrenschmidt wrote:
> > On Sat, 2013-11-02 at 08:58 -0700, Greg Kroah-Hartman wrote:
> > > Just loop through all the platform devices before registering it to
> > > determine if you ne
On Sat, 2 Nov 2013 08:58:24 -0700 Greg Kroah-Hartman
wrote:
> So go blame them for this, not me, remember, I'm the one who _hates_
> platform devices and wish they had never been created...
Have you ever written up why you hate them? I did a bit of googling and
couldn't find anything obvious.
On Sun, Nov 03, 2013 at 07:22:10AM +1100, Benjamin Herrenschmidt wrote:
> On Sat, 2013-11-02 at 08:58 -0700, Greg Kroah-Hartman wrote:
> > Just loop through all the platform devices before registering it to
> > determine if you need to do this, the platform code can do this just
> > fine. If you t
On Sat, 2013-11-02 at 08:58 -0700, Greg Kroah-Hartman wrote:
> Just loop through all the platform devices before registering it to
> determine if you need to do this, the platform code can do this just
> fine. If you try to register a duplicate name with the driver core,
> odds are it will complai
On Sat, Nov 02, 2013 at 10:09:59AM +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2013-11-01 at 13:47 -0700, Greg Kroah-Hartman wrote:
>
> > > > On my device I seem to have some platform devices registered through
> > > > device-tree, and some registered through platform_device_add (e.g.
> > > > '
On Sat, 02 Nov 2013 10:10:25 +1100 Benjamin Herrenschmidt
wrote:
> On Fri, 2013-11-01 at 13:47 -0700, Greg Kroah-Hartman wrote:
>
> > > > On my device I seem to have some platform devices registered through
> > > > device-tree, and some registered through platform_device_add (e.g.
> > > > 'alarm
On Fri, 2013-11-01 at 13:47 -0700, Greg Kroah-Hartman wrote:
> > > On my device I seem to have some platform devices registered through
> > > device-tree, and some registered through platform_device_add (e.g.
> > > 'alarmtimer'). Guaranteeing they remain disjoint sets if the kernel is
> > > allow
On Fri, 2013-11-01 at 13:47 -0700, Greg Kroah-Hartman wrote:
> > > On my device I seem to have some platform devices registered through
> > > device-tree, and some registered through platform_device_add (e.g.
> > > 'alarmtimer'). Guaranteeing they remain disjoint sets if the kernel is
> > > allow
On Fri, Nov 01, 2013 at 11:04:59AM -0700, Grant Likely wrote:
> Second, I expect there is going to be userspace breakage to move them.
> I've considered moving them before, but so far have felt that being
> tidier hasn't been worth the potential breakage. Userspace /shouldn't/
> be relying on the n
On Fri, Nov 01, 2013 at 04:08:36PM +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2013-11-01 at 16:03 +1100, NeilBrown wrote:
>
> > Do you mean we could allow multiple devices on the one bus to have the same
> > name, but get sysfs to notice and de-duplicate by mangling one name? I
> > don't
> >
On Fri, 2013-11-01 at 11:04 -0700, Grant Likely wrote:
> There are two problems here. First, making the change moves all the DT
> populated devices under the /sys/devices/platform tree, not just
> platform devices.
All DT populated *platform* devices. There are others that have their
own location
On Fri, 01 Nov 2013 16:08:36 +1100, Benjamin Herrenschmidt
wrote:
> On Fri, 2013-11-01 at 16:03 +1100, NeilBrown wrote:
>
> > Do you mean we could allow multiple devices on the one bus to have the same
> > name, but get sysfs to notice and de-duplicate by mangling one name? I
> > don't
> > thi
On Fri, 2013-11-01 at 16:03 +1100, NeilBrown wrote:
> Do you mean we could allow multiple devices on the one bus to have the same
> name, but get sysfs to notice and de-duplicate by mangling one name? I don't
> think I like that but I might have misunderstood.
What other option do we have ?
> O
On Fri, 01 Nov 2013 15:27:34 +1100 Benjamin Herrenschmidt
wrote:
> On Fri, 2013-11-01 at 15:22 +1100, Benjamin Herrenschmidt wrote:
> > On Fri, 2013-11-01 at 14:59 +1100, NeilBrown wrote:
> > > and I wonder how relevant it still is in this context. As platform
> > > devices
> > > are all in the
On Fri, 2013-11-01 at 15:22 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2013-11-01 at 14:59 +1100, NeilBrown wrote:
> > and I wonder how relevant it still is in this context. As platform devices
> > are all in the root of the device-tree and hence are siblings, they must
> > have
> > unique na
On Fri, 2013-11-01 at 14:59 +1100, NeilBrown wrote:
> and I wonder how relevant it still is in this context. As platform devices
> are all in the root of the device-tree and hence are siblings, they must have
> unique names in the device-tree and so the platform devices created from
> them will a
Eric Dumazet wrote:
> On Fri, 2013-07-19 at 23:50 +, Eric Wong wrote:
> > Eric Dumazet wrote:
> > > Hi Al
> > >
> > > I tried to debug strange crashes in tcp_poll() called from
> > > sys_epoll_wait() -> sock_poll()
> > >
> > > The symptom is that sock->sk is NULL and we therefore dereferenc
On Fri, 2013-07-19 at 23:50 +, Eric Wong wrote:
> Eric Dumazet wrote:
> > Hi Al
> >
> > I tried to debug strange crashes in tcp_poll() called from
> > sys_epoll_wait() -> sock_poll()
> >
> > The symptom is that sock->sk is NULL and we therefore dereference a NULL
> > pointer.
> >
> > It's r
Eric Dumazet wrote:
> Hi Al
>
> I tried to debug strange crashes in tcp_poll() called from
> sys_epoll_wait() -> sock_poll()
>
> The symptom is that sock->sk is NULL and we therefore dereference a NULL
> pointer.
>
> It's really rare crashes but still, it would be nice to understand where
> is
On 2013.06.13 at 10:16 -0400, Peter Hurley wrote:
> On 06/13/2013 06:39 AM, Markus Trippelsdorf wrote:
> > On 2013.06.07 at 20:22 +0200, Mikael Pettersson wrote:
> >> Peter Hurley writes:
> >> > Based on the other reports from Mikael and David, I suspect this
> >> problem
> >> > may have to do
On 06/13/2013 06:39 AM, Markus Trippelsdorf wrote:
On 2013.06.07 at 20:22 +0200, Mikael Pettersson wrote:
Peter Hurley writes:
> Based on the other reports from Mikael and David, I suspect this problem
> may have to do with my commit 699390354da6c258b65bf8fa79cfd5feaede50b6:
>
>pty:
On 2013.06.11 at 22:14 +, Orion Poplawski wrote:
> Peter Hurley hurleysoftware.com> writes:
> > Based on the other reports from Mikael and David, I suspect this problem
> > may have to do with my commit 699390354da6c258b65bf8fa79cfd5feaede50b6:
> >
> >pty: Ignore slave pty close() if neve
1 - 100 of 422 matches
Mail list logo
