On 07/12/2016 04:54 AM, Jiri Kosina wrote:
On Mon, 11 Jul 2016, Mark Hounschell wrote:
Well, all that was specified in my original post. I can no longer open the
floppy drive with no floppy media inserted. Worse, I can also no longer open a
floppy with media inserted that is not a "linux"
On 07/12/2016 04:54 AM, Jiri Kosina wrote:
On Mon, 11 Jul 2016, Mark Hounschell wrote:
Well, all that was specified in my original post. I can no longer open the
floppy drive with no floppy media inserted. Worse, I can also no longer open a
floppy with media inserted that is not a "linux"
On Fri, 12 Aug 2016, Mark Hounschell wrote:
> > Is there some minimalized reproducer you are seeing the regression with
> > that you could share?
> >
> > Thanks,
>
> Your patch is NOT there yet.
We're talking about ff06db1ef.
--
Jiri Kosina
SUSE Labs
On Fri, 12 Aug 2016, Mark Hounschell wrote:
> > Is there some minimalized reproducer you are seeing the regression with
> > that you could share?
> >
> > Thanks,
>
> Your patch is NOT there yet.
We're talking about ff06db1ef.
--
Jiri Kosina
SUSE Labs
On 08/12/2016 05:37 AM, Jiri Kosina wrote:
On Thu, 11 Aug 2016, Mark Hounschell wrote:
I just tested what is currently in Linus' tree and it does NOT work for
me.
Is there some minimalized reproducer you are seeing the regression with
that you could share?
Thanks,
Your patch is NOT there
On 08/12/2016 05:37 AM, Jiri Kosina wrote:
On Thu, 11 Aug 2016, Mark Hounschell wrote:
I just tested what is currently in Linus' tree and it does NOT work for
me.
Is there some minimalized reproducer you are seeing the regression with
that you could share?
Thanks,
Your patch is NOT there
On Thu, 11 Aug 2016, Mark Hounschell wrote:
> I just tested what is currently in Linus' tree and it does NOT work for
> me.
Is there some minimalized reproducer you are seeing the regression with
that you could share?
Thanks,
--
Jiri Kosina
SUSE Labs
On Thu, 11 Aug 2016, Mark Hounschell wrote:
> I just tested what is currently in Linus' tree and it does NOT work for
> me.
Is there some minimalized reproducer you are seeing the regression with
that you could share?
Thanks,
--
Jiri Kosina
SUSE Labs
On 08/11/2016 09:24 AM, Jiri Kosina wrote:
On Wed, 3 Aug 2016, Mark Hounschell wrote:
I'm not sure how to get "for-linus" branch. I don't see it in linux-block.git.
It's there.
A patch for 4.5 would be easy for me though.
Anyway the commit landed in Linus' tree already (ff06db1ef).
On 08/11/2016 09:24 AM, Jiri Kosina wrote:
On Wed, 3 Aug 2016, Mark Hounschell wrote:
I'm not sure how to get "for-linus" branch. I don't see it in linux-block.git.
It's there.
A patch for 4.5 would be easy for me though.
Anyway the commit landed in Linus' tree already (ff06db1ef).
On Wed, 3 Aug 2016, Mark Hounschell wrote:
> I'm not sure how to get "for-linus" branch. I don't see it in linux-block.git.
It's there.
> A patch for 4.5 would be easy for me though.
Anyway the commit landed in Linus' tree already (ff06db1ef). Testing it in
your environment would be
On Wed, 3 Aug 2016, Mark Hounschell wrote:
> I'm not sure how to get "for-linus" branch. I don't see it in linux-block.git.
It's there.
> A patch for 4.5 would be easy for me though.
Anyway the commit landed in Linus' tree already (ff06db1ef). Testing it in
your environment would be
On 08/02/2016 05:44 AM, Jiri Kosina wrote:
On Wed, 13 Jul 2016, Mark Hounschell wrote:
Alright, so you are basically supplementing O_NDELAY flag in order to
avoid check_disk_change() being called. It's rather a coincidence that
it has worked this way, but I agree with you that we can't ignore
On 08/02/2016 05:44 AM, Jiri Kosina wrote:
On Wed, 13 Jul 2016, Mark Hounschell wrote:
Alright, so you are basically supplementing O_NDELAY flag in order to
avoid check_disk_change() being called. It's rather a coincidence that
it has worked this way, but I agree with you that we can't ignore
On Wed, 13 Jul 2016, Mark Hounschell wrote:
> > Alright, so you are basically supplementing O_NDELAY flag in order to
> > avoid check_disk_change() being called. It's rather a coincidence that
> > it has worked this way, but I agree with you that we can't ignore the
> > fact that there is
On Wed, 13 Jul 2016, Mark Hounschell wrote:
> > Alright, so you are basically supplementing O_NDELAY flag in order to
> > avoid check_disk_change() being called. It's rather a coincidence that
> > it has worked this way, but I agree with you that we can't ignore the
> > fact that there is
On 07/12/2016 04:54 AM, Jiri Kosina wrote:
On Mon, 11 Jul 2016, Mark Hounschell wrote:
Well, all that was specified in my original post. I can no longer open the
floppy drive with no floppy media inserted. Worse, I can also no longer open a
floppy with media inserted that is not a "linux"
On 07/12/2016 04:54 AM, Jiri Kosina wrote:
On Mon, 11 Jul 2016, Mark Hounschell wrote:
Well, all that was specified in my original post. I can no longer open the
floppy drive with no floppy media inserted. Worse, I can also no longer open a
floppy with media inserted that is not a "linux"
On Mon, 11 Jul 2016, Mark Hounschell wrote:
> Well, all that was specified in my original post. I can no longer open the
> floppy drive with no floppy media inserted. Worse, I can also no longer open a
> floppy with media inserted that is not a "linux" recognized format. A floppy
> drive is a
On Mon, 11 Jul 2016, Mark Hounschell wrote:
> Well, all that was specified in my original post. I can no longer open the
> floppy drive with no floppy media inserted. Worse, I can also no longer open a
> floppy with media inserted that is not a "linux" recognized format. A floppy
> drive is a
On 07/11/2016 11:36 AM, Jiri Kosina wrote:
On Tue, 5 Jul 2016, Mark Hounschell wrote:
From: Jiri Kosina
Commit 09954bad4 ("floppy: refactor open() flags handling"), as a
side-effect, causes open(/dev/fdX, O_ACCMODE) to fail. It turns out that
this is being used setfdprm
On 07/11/2016 11:36 AM, Jiri Kosina wrote:
On Tue, 5 Jul 2016, Mark Hounschell wrote:
From: Jiri Kosina
Commit 09954bad4 ("floppy: refactor open() flags handling"), as a
side-effect, causes open(/dev/fdX, O_ACCMODE) to fail. It turns out that
this is being used setfdprm userspace for
On Tue, 5 Jul 2016, Mark Hounschell wrote:
> From: Jiri Kosina
>
> Commit 09954bad4 ("floppy: refactor open() flags handling"), as a
> side-effect, causes open(/dev/fdX, O_ACCMODE) to fail. It turns out that
> this is being used setfdprm userspace for ioctl-only open().
>
>
On Tue, 5 Jul 2016, Mark Hounschell wrote:
> From: Jiri Kosina
>
> Commit 09954bad4 ("floppy: refactor open() flags handling"), as a
> side-effect, causes open(/dev/fdX, O_ACCMODE) to fail. It turns out that
> this is being used setfdprm userspace for ioctl-only open().
>
> Reintroduce back
Just rejoined the list due to floppy open problems created from 4.4 to
4.5. I found the following email that indicates a fix for one of the
problems.
From: Jiri Kosina
Commit 09954bad4 ("floppy: refactor open() flags handling"), as a
side-effect, causes open(/dev/fdX,
Just rejoined the list due to floppy open problems created from 4.4 to
4.5. I found the following email that indicates a fix for one of the
problems.
From: Jiri Kosina
Commit 09954bad4 ("floppy: refactor open() flags handling"), as a
side-effect, causes open(/dev/fdX, O_ACCMODE) to fail.
26 matches
Mail list logo