On 09/18/2016 10:17 AM, Rich Felker wrote:
> On Sat, Sep 17, 2016 at 11:40:28PM -0500, Rob Landley wrote:
>>
>>
>> On 09/16/2016 09:23 PM, Guenter Roeck wrote:
>>> On 09/16/2016 04:32 PM, Rich Felker wrote:
> 4.6.3 from kernel.org.
That is utterly ancient and probaby very buggy. I
On 09/18/2016 10:17 AM, Rich Felker wrote:
> On Sat, Sep 17, 2016 at 11:40:28PM -0500, Rob Landley wrote:
>>
>>
>> On 09/16/2016 09:23 PM, Guenter Roeck wrote:
>>> On 09/16/2016 04:32 PM, Rich Felker wrote:
> 4.6.3 from kernel.org.
That is utterly ancient and probaby very buggy. I
On Sat, Sep 17, 2016 at 11:40:28PM -0500, Rob Landley wrote:
>
>
> On 09/16/2016 09:23 PM, Guenter Roeck wrote:
> > On 09/16/2016 04:32 PM, Rich Felker wrote:
> >>> 4.6.3 from kernel.org.
> >>
> >> That is utterly ancient and probaby very buggy. I would recommend 5.x+
> >> or at the very least
On Sat, Sep 17, 2016 at 11:40:28PM -0500, Rob Landley wrote:
>
>
> On 09/16/2016 09:23 PM, Guenter Roeck wrote:
> > On 09/16/2016 04:32 PM, Rich Felker wrote:
> >>> 4.6.3 from kernel.org.
> >>
> >> That is utterly ancient and probaby very buggy. I would recommend 5.x+
> >> or at the very least
On 09/16/2016 09:23 PM, Guenter Roeck wrote:
> On 09/16/2016 04:32 PM, Rich Felker wrote:
>>> 4.6.3 from kernel.org.
>>
>> That is utterly ancient and probaby very buggy. I would recommend 5.x+
>> or at the very least 4.7 or 4.8.
>>
> Unfortunately that is the latest one available from
On 09/16/2016 09:23 PM, Guenter Roeck wrote:
> On 09/16/2016 04:32 PM, Rich Felker wrote:
>>> 4.6.3 from kernel.org.
>>
>> That is utterly ancient and probaby very buggy. I would recommend 5.x+
>> or at the very least 4.7 or 4.8.
>>
> Unfortunately that is the latest one available from
On 09/16/2016 04:32 PM, Rich Felker wrote:
[ ... ]
It would be useful to know what compiler version was used to build the
kernel. I wouldn't be surprised if some are buggy.
4.6.3 from kernel.org.
That is utterly ancient and probaby very buggy. I would recommend 5.x+
or at the very least 4.7
On 09/16/2016 04:32 PM, Rich Felker wrote:
[ ... ]
It would be useful to know what compiler version was used to build the
kernel. I wouldn't be surprised if some are buggy.
4.6.3 from kernel.org.
That is utterly ancient and probaby very buggy. I would recommend 5.x+
or at the very least 4.7
On 09/16/2016 04:32 PM, Rich Felker wrote:
4.6.3 from kernel.org.
That is utterly ancient and probaby very buggy. I would recommend 5.x+
or at the very least 4.7 or 4.8.
Unfortunately that is the latest one available from kernel.org :-(.
I'll try to build one myself.
Thanks,
Guenter
On 09/16/2016 04:32 PM, Rich Felker wrote:
4.6.3 from kernel.org.
That is utterly ancient and probaby very buggy. I would recommend 5.x+
or at the very least 4.7 or 4.8.
Unfortunately that is the latest one available from kernel.org :-(.
I'll try to build one myself.
Thanks,
Guenter
On Fri, Sep 16, 2016 at 03:47:44PM -0700, Guenter Roeck wrote:
> On Fri, Sep 16, 2016 at 05:39:18PM -0400, Rich Felker wrote:
> > On Fri, Sep 16, 2016 at 10:31:41PM +0100, Al Viro wrote:
> > > On Fri, Sep 16, 2016 at 01:59:38PM -0700, Guenter Roeck wrote:
> > > > Yes, reverting 6e050503a150 fixes
On Fri, Sep 16, 2016 at 03:47:44PM -0700, Guenter Roeck wrote:
> On Fri, Sep 16, 2016 at 05:39:18PM -0400, Rich Felker wrote:
> > On Fri, Sep 16, 2016 at 10:31:41PM +0100, Al Viro wrote:
> > > On Fri, Sep 16, 2016 at 01:59:38PM -0700, Guenter Roeck wrote:
> > > > Yes, reverting 6e050503a150 fixes
On Fri, Sep 16, 2016 at 03:47:04PM -0700, Guenter Roeck wrote:
> Adding pr_info() just before the "if (unlikely..." fixes the problem.
>
> Commenting out the "if (unlikely())" code fixes the problem.
>
> Using a new variable "unsigned long x" for the return code instead of
> re-using
On Fri, Sep 16, 2016 at 03:47:04PM -0700, Guenter Roeck wrote:
> Adding pr_info() just before the "if (unlikely..." fixes the problem.
>
> Commenting out the "if (unlikely())" code fixes the problem.
>
> Using a new variable "unsigned long x" for the return code instead of
> re-using
On Fri, Sep 16, 2016 at 05:39:18PM -0400, Rich Felker wrote:
> On Fri, Sep 16, 2016 at 10:31:41PM +0100, Al Viro wrote:
> > On Fri, Sep 16, 2016 at 01:59:38PM -0700, Guenter Roeck wrote:
> > > Yes, reverting 6e050503a150 fixes the problem.
> > >
> > > I added a BUG() into the "if (unlikely())"
On Fri, Sep 16, 2016 at 05:39:18PM -0400, Rich Felker wrote:
> On Fri, Sep 16, 2016 at 10:31:41PM +0100, Al Viro wrote:
> > On Fri, Sep 16, 2016 at 01:59:38PM -0700, Guenter Roeck wrote:
> > > Yes, reverting 6e050503a150 fixes the problem.
> > >
> > > I added a BUG() into the "if (unlikely())"
On Fri, Sep 16, 2016 at 10:31:41PM +0100, Al Viro wrote:
> On Fri, Sep 16, 2016 at 01:59:38PM -0700, Guenter Roeck wrote:
> > Yes, reverting 6e050503a150 fixes the problem.
> >
> > I added a BUG() into the "if (unlikely())" below, but it doesn't catch,
> > and I still get the ip: OVERRUN errors.
On Fri, Sep 16, 2016 at 10:31:41PM +0100, Al Viro wrote:
> On Fri, Sep 16, 2016 at 01:59:38PM -0700, Guenter Roeck wrote:
> > Yes, reverting 6e050503a150 fixes the problem.
> >
> > I added a BUG() into the "if (unlikely())" below, but it doesn't catch,
> > and I still get the ip: OVERRUN errors.
On Fri, Sep 16, 2016 at 10:31:41PM +0100, Al Viro wrote:
> On Fri, Sep 16, 2016 at 01:59:38PM -0700, Guenter Roeck wrote:
> > Yes, reverting 6e050503a150 fixes the problem.
> >
> > I added a BUG() into the "if (unlikely())" below, but it doesn't catch,
> > and I still get the ip: OVERRUN errors.
On Fri, Sep 16, 2016 at 10:31:41PM +0100, Al Viro wrote:
> On Fri, Sep 16, 2016 at 01:59:38PM -0700, Guenter Roeck wrote:
> > Yes, reverting 6e050503a150 fixes the problem.
> >
> > I added a BUG() into the "if (unlikely())" below, but it doesn't catch,
> > and I still get the ip: OVERRUN errors.
On Fri, Sep 16, 2016 at 01:59:38PM -0700, Guenter Roeck wrote:
> Yes, reverting 6e050503a150 fixes the problem.
>
> I added a BUG() into the "if (unlikely())" below, but it doesn't catch,
> and I still get the ip: OVERRUN errors. Which leaves me a bit puzzled.
>
> Guenter
>
> > The change in
On Fri, Sep 16, 2016 at 01:59:38PM -0700, Guenter Roeck wrote:
> Yes, reverting 6e050503a150 fixes the problem.
>
> I added a BUG() into the "if (unlikely())" below, but it doesn't catch,
> and I still get the ip: OVERRUN errors. Which leaves me a bit puzzled.
>
> Guenter
>
> > The change in
On Fri, Sep 16, 2016 at 01:32:05PM -0700, Guenter Roeck wrote:
> > BTW, could you post your .config and information about your userland? E.g.
> > is that ip(8) a busybox one, etc. If it's busybox, this smells like EINVAL
> > and EFAULT resp. coming from recvmsg() on netlink sockets, with nothing
On Fri, Sep 16, 2016 at 01:32:05PM -0700, Guenter Roeck wrote:
> > BTW, could you post your .config and information about your userland? E.g.
> > is that ip(8) a busybox one, etc. If it's busybox, this smells like EINVAL
> > and EFAULT resp. coming from recvmsg() on netlink sockets, with nothing
On Fri, Sep 16, 2016 at 08:45:33PM +0100, Al Viro wrote:
> On Fri, Sep 16, 2016 at 12:12:18PM -0700, Guenter Roeck wrote:
> > Hi,
> >
> > I see the following runtime failure when running a 'sh' image with qemu in
> > -next.
>
> > Bisect points to commit 6e050503a150 ("sh: fix
On Fri, Sep 16, 2016 at 08:45:33PM +0100, Al Viro wrote:
> On Fri, Sep 16, 2016 at 12:12:18PM -0700, Guenter Roeck wrote:
> > Hi,
> >
> > I see the following runtime failure when running a 'sh' image with qemu in
> > -next.
>
> > Bisect points to commit 6e050503a150 ("sh: fix
On Fri, Sep 16, 2016 at 01:32:05PM -0700, Guenter Roeck wrote:
> On Fri, Sep 16, 2016 at 09:03:20PM +0100, Al Viro wrote:
> > On Fri, Sep 16, 2016 at 12:12:18PM -0700, Guenter Roeck wrote:
> > > Hi,
> > >
> > > I see the following runtime failure when running a 'sh' image with qemu
> > > in
On Fri, Sep 16, 2016 at 01:32:05PM -0700, Guenter Roeck wrote:
> On Fri, Sep 16, 2016 at 09:03:20PM +0100, Al Viro wrote:
> > On Fri, Sep 16, 2016 at 12:12:18PM -0700, Guenter Roeck wrote:
> > > Hi,
> > >
> > > I see the following runtime failure when running a 'sh' image with qemu
> > > in
On Fri, Sep 16, 2016 at 09:03:20PM +0100, Al Viro wrote:
> On Fri, Sep 16, 2016 at 12:12:18PM -0700, Guenter Roeck wrote:
> > Hi,
> >
> > I see the following runtime failure when running a 'sh' image with qemu in
> > -next.
> >
> > [ ... ]
> >
> > sd 0:0:0:0: [sda] Attached SCSI disk
> >
On Fri, Sep 16, 2016 at 09:03:20PM +0100, Al Viro wrote:
> On Fri, Sep 16, 2016 at 12:12:18PM -0700, Guenter Roeck wrote:
> > Hi,
> >
> > I see the following runtime failure when running a 'sh' image with qemu in
> > -next.
> >
> > [ ... ]
> >
> > sd 0:0:0:0: [sda] Attached SCSI disk
> >
On Fri, Sep 16, 2016 at 12:12:18PM -0700, Guenter Roeck wrote:
> Hi,
>
> I see the following runtime failure when running a 'sh' image with qemu in
> -next.
>
> [ ... ]
>
> sd 0:0:0:0: [sda] Attached SCSI disk
> EXT2-fs (sda): warning: mounting unchecked fs, running e2fsck is recommended
>
On Fri, Sep 16, 2016 at 12:12:18PM -0700, Guenter Roeck wrote:
> Hi,
>
> I see the following runtime failure when running a 'sh' image with qemu in
> -next.
>
> [ ... ]
>
> sd 0:0:0:0: [sda] Attached SCSI disk
> EXT2-fs (sda): warning: mounting unchecked fs, running e2fsck is recommended
>
On Fri, Sep 16, 2016 at 12:12:18PM -0700, Guenter Roeck wrote:
> Hi,
>
> I see the following runtime failure when running a 'sh' image with qemu in
> -next.
> Bisect points to commit 6e050503a150 ("sh: fix copy_from_user()"). Bisect log
> is
> attached.
Does reverting it recover the thing?
On Fri, Sep 16, 2016 at 12:12:18PM -0700, Guenter Roeck wrote:
> Hi,
>
> I see the following runtime failure when running a 'sh' image with qemu in
> -next.
> Bisect points to commit 6e050503a150 ("sh: fix copy_from_user()"). Bisect log
> is
> attached.
Does reverting it recover the thing?
Hi,
I see the following runtime failure when running a 'sh' image with qemu in
-next.
[ ... ]
sd 0:0:0:0: [sda] Attached SCSI disk
EXT2-fs (sda): warning: mounting unchecked fs, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem) on device 8:0.
Freeing unused kernel memory: 124K
Hi,
I see the following runtime failure when running a 'sh' image with qemu in
-next.
[ ... ]
sd 0:0:0:0: [sda] Attached SCSI disk
EXT2-fs (sda): warning: mounting unchecked fs, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem) on device 8:0.
Freeing unused kernel memory: 124K
36 matches
Mail list logo