On Mon, Feb 06, 2017 at 03:54:56PM +0100, Martin Pieuchot wrote:
> On 06/02/17(Mon) 12:27, Martin Pieuchot wrote:
> > Paul and Antoine reported that, since the NET_LOCK() went in, doing a
> > channel scan with iwm(4) and iwn(4) freezes X.
> >
> > This is a deadlock due to the fact that wireless
On Mon, Feb 06, 2017 at 03:54:56PM +0100, Martin Pieuchot wrote:
> tb@ found that another code path needs to be unlocked. Diff below does
> that. These ioctl(2)s are only messing at the driver level, so it is
> safe to drop the NET_LOCK() there as well.
>
> ok?
I am happy with this. OK.
And
On 06/02/17(Mon) 12:27, Martin Pieuchot wrote:
> Paul and Antoine reported that, since the NET_LOCK() went in, doing a
> channel scan with iwm(4) and iwn(4) freezes X.
>
> This is a deadlock due to the fact that wireless drivers sleep during
> a long time holding the NET_LOCK() while the X server
On 06/02/17(Mon) 12:59, Stefan Sperling wrote:
> On Mon, Feb 06, 2017 at 12:44:52PM +0100, Martin Pieuchot wrote:
> > On 06/02/17(Mon) 12:39, Theo Buehler wrote:
> > > This fixes the issue on my iwn0, but re-introduces the problem on my iwm0.
> >
> > That means another ioctl(2) triggers the
On Mon, Feb 06, 2017 at 12:44:52PM +0100, Martin Pieuchot wrote:
> On 06/02/17(Mon) 12:39, Theo Buehler wrote:
> > This fixes the issue on my iwn0, but re-introduces the problem on my iwm0.
>
> That means another ioctl(2) triggers the problem with iwm(4). It would
> help if you could figure out
On 06/02/17(Mon) 12:39, Theo Buehler wrote:
> On Mon, Feb 06, 2017 at 12:27:15PM +0100, Martin Pieuchot wrote:
> > Paul and Antoine reported that, since the NET_LOCK() went in, doing a
> > channel scan with iwm(4) and iwn(4) freezes X.
> >
> > This is a deadlock due to the fact that wireless
On Mon, Feb 06, 2017 at 12:27:15PM +0100, Martin Pieuchot wrote:
> Paul and Antoine reported that, since the NET_LOCK() went in, doing a
> channel scan with iwm(4) and iwn(4) freezes X.
>
> This is a deadlock due to the fact that wireless drivers sleep during
> a long time holding the NET_LOCK()
Paul and Antoine reported that, since the NET_LOCK() went in, doing a
channel scan with iwm(4) and iwn(4) freezes X.
This is a deadlock due to the fact that wireless drivers sleep during
a long time holding the NET_LOCK() while the X server tries to
communicate with unix sockets, that still need
