On 6/26/20 12:06 AM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20200625:
>
on x86_64:
ld: net/core/filter.o: in function `bpf_skc_to_tcp_timewait_sock':
filter.c:(.text+0x101b): undefined reference to `tcp_prot'
ld: net/core/filter.o: in function `bpf_skc_to_tcp_request_sock':
On 6/26/20 12:06 AM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20200625:
>
on i386 or x86_64:
../mm/memory-failure.c: In function ‘__soft_offline_page’:
../mm/memory-failure.c:1827:3: error: implicit declaration of function
‘page_handle_poison’; did you mean ‘page_init_poison’?
Hi all,
Changes since 20200625:
My fixes tree contains:
466d58f824f1 ("device_cgroup: Fix RCU list debugging warning")
9bd7b7c45d71 ("sched: Fix RANDSTRUCT build fail")
2f437faecf71 ("powerpc/boot/dts: Fix dtc "pciex" warnings")
The bpf-next tree gained a conflict against the bpf tree.
On 6/27/19 6:29 AM, David Howells wrote:
> Mimi Zohar wrote:
>
>>> CC security/integrity/ima/ima_fs.o
>>> In file included from ../security/integrity/ima/ima.h:25:0,
>>> from ../security/integrity/ima/ima_fs.c:26:
>>> ../security/integrity/ima/../integrity.h:170:18:
Mimi Zohar wrote:
> > CC security/integrity/ima/ima_fs.o
> > In file included from ../security/integrity/ima/ima.h:25:0,
> > from ../security/integrity/ima/ima_fs.c:26:
> > ../security/integrity/ima/../integrity.h:170:18: warning: ‘struct key_acl’
> > declared inside
[Cc'ing David Howells]
On Wed, 2019-06-26 at 11:35 -0700, Randy Dunlap wrote:
> On 6/26/19 6:16 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > The sparc64 builds are broken in this tree, sorry.
> >
> > Changes since 20190625:
> >
>
> on x86_64:
>
> 11 warnings like this one (in a randconfig
Randy Dunlap wrote:
> Multiple build errors like this when CONFIG_KEYS is not set/enabled:
> (this was seen on one i386 build)
Ah - I forgot to make CONFIG_KEYS_REQUEST_CACHE depend on CONFIG_KEYS.
David
On 6/26/19 6:16 AM, Stephen Rothwell wrote:
> Hi all,
>
> The sparc64 builds are broken in this tree, sorry.
>
> Changes since 20190625:
>
on x86_64:
11 warnings like this one (in a randconfig build):
CC security/integrity/ima/ima_fs.o
In file included from
On 6/26/19 6:16 AM, Stephen Rothwell wrote:
> Hi all,
>
> The sparc64 builds are broken in this tree, sorry.
>
> Changes since 20190625:
>
>
> The keys tree gained conflicts aginst the ecryptfs and integrity trees.
Multiple build errors like this when CONFIG_KEYS is not set/enabled:
(this was
Hi all,
The sparc64 builds are broken in this tree, sorry.
Changes since 20190625:
The fbdev tree still had its build failure for which I reverted 2 commits.
The net-next tree still had its build failure for which I reverted a commit.
The amdgpu tree lost its build failure, but gained another
Hi all,
Changes since 20180625:
The cifs tree lost its build failure.
The drm tree still had its build failure for which I disabled some
sample code.
The nvdimm tree gained a conflict against the tip tree.
Non-merge commits (relative to Linus' tree): 2240
2288 files changed, 72718
Hi all,
Changes since 20180625:
The cifs tree lost its build failure.
The drm tree still had its build failure for which I disabled some
sample code.
The nvdimm tree gained a conflict against the tip tree.
Non-merge commits (relative to Linus' tree): 2240
2288 files changed, 72718
Hi all,
Changes since 20170623:
Tree changed owner/URL: chrome-platform
The pci tree gained a conflict against Linus' tree.
The i2c tree gained a build failure so I used the version from
next-20170623.
The jc_docs tree gained a conflict against the kbuild tree.
The block tree gained
Hi all,
Changes since 20170623:
Tree changed owner/URL: chrome-platform
The pci tree gained a conflict against Linus' tree.
The i2c tree gained a build failure so I used the version from
next-20170623.
The jc_docs tree gained a conflict against the kbuild tree.
The block tree gained
On 26/06/15 10:08, Stephen Rothwell wrote:
Hi all,
Changes since 20150625:
Dropped tree: edac-amd (rebased and merged into Linus' tree)
The arc tree gained a conflict against Linus' tree.
The vfs tree gained a conflict against the ceph tree.
The modules tree still had its build failure so I
Hi all,
Changes since 20150625:
Dropped tree: edac-amd (rebased and merged into Linus' tree)
The arc tree gained a conflict against Linus' tree.
The vfs tree gained a conflict against the ceph tree.
The modules tree still had its build failure so I applied another patch.
The edac-amd tree
On 26/06/15 10:08, Stephen Rothwell wrote:
Hi all,
Changes since 20150625:
Dropped tree: edac-amd (rebased and merged into Linus' tree)
The arc tree gained a conflict against Linus' tree.
The vfs tree gained a conflict against the ceph tree.
The modules tree still had its build failure so I
Hi all,
Changes since 20150625:
Dropped tree: edac-amd (rebased and merged into Linus' tree)
The arc tree gained a conflict against Linus' tree.
The vfs tree gained a conflict against the ceph tree.
The modules tree still had its build failure so I applied another patch.
The edac-amd tree
inux
> Subject: Re: linux-next: Tree for Jun 26 (crypto/qat)
>
> On 06/26/14 08:04, Randy Dunlap wrote:
> > On 06/25/14 23:41, Stephen Rothwell wrote:
> >> Hi all,
> >>
> >> The powerpc allyesconfig is again broken more than usual.
> >>
> >
On 06/25/14 23:41, Stephen Rothwell wrote:
> Hi all,
>
> The powerpc allyesconfig is again broken more than usual.
>
> Changes since 20140625:
>
on i386:
../crypto/drbg.c:1097:3: warning: format '%lu' expects argument of type 'long
unsigned int', but argument 2 has type 'size_t' [-Wformat]
On 06/26/14 08:04, Randy Dunlap wrote:
> On 06/25/14 23:41, Stephen Rothwell wrote:
>> Hi all,
>>
>> The powerpc allyesconfig is again broken more than usual.
>>
>> Changes since 20140625:
>>
>
> on x86_64:
>
> CC drivers/crypto/qat/qat_dh895xcc/adf_dh895xcc_hw_data.o
>
On 06/25/14 23:41, Stephen Rothwell wrote:
> Hi all,
>
> The powerpc allyesconfig is again broken more than usual.
>
> Changes since 20140625:
>
on x86_64:
CC drivers/crypto/qat/qat_dh895xcc/adf_dh895xcc_hw_data.o
../drivers/crypto/qat/qat_dh895xcc/adf_dh895xcc_hw_data.c: In function
Hi all,
The powerpc allyesconfig is again broken more than usual.
Changes since 20140625:
New tree: usb-serial
The staging tree still had its build failure for which I disabled a driver.
The akpm-current tree gained a build failure for which I reverted a commit.
Non-merge commits (relative
Hi all,
The powerpc allyesconfig is again broken more than usual.
Changes since 20140625:
New tree: usb-serial
The staging tree still had its build failure for which I disabled a driver.
The akpm-current tree gained a build failure for which I reverted a commit.
Non-merge commits (relative
On 06/25/14 23:41, Stephen Rothwell wrote:
Hi all,
The powerpc allyesconfig is again broken more than usual.
Changes since 20140625:
on x86_64:
CC drivers/crypto/qat/qat_dh895xcc/adf_dh895xcc_hw_data.o
../drivers/crypto/qat/qat_dh895xcc/adf_dh895xcc_hw_data.c: In function
On 06/26/14 08:04, Randy Dunlap wrote:
On 06/25/14 23:41, Stephen Rothwell wrote:
Hi all,
The powerpc allyesconfig is again broken more than usual.
Changes since 20140625:
on x86_64:
CC drivers/crypto/qat/qat_dh895xcc/adf_dh895xcc_hw_data.o
On 06/25/14 23:41, Stephen Rothwell wrote:
Hi all,
The powerpc allyesconfig is again broken more than usual.
Changes since 20140625:
on i386:
../crypto/drbg.c:1097:3: warning: format '%lu' expects argument of type 'long
unsigned int', but argument 2 has type 'size_t' [-Wformat]
-next: Tree for Jun 26 (crypto/qat)
On 06/26/14 08:04, Randy Dunlap wrote:
On 06/25/14 23:41, Stephen Rothwell wrote:
Hi all,
The powerpc allyesconfig is again broken more than usual.
Changes since 20140625:
on x86_64:
CC drivers/crypto/qat/qat_dh895xcc
On Wed, Jun 26, 2013 at 11:48:58AM -0700, Randy Dunlap wrote:
> On 06/26/13 01:06, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20130625:
> >
>
> CONFIG_SMP is not set
> CONFIG_X86_UP_APIC is not set
That is new. Any thoughts of which patch might be the culprit?
What are the other
On 06/26/13 01:06, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20130625:
>
CONFIG_SMP is not set
CONFIG_X86_UP_APIC is not set
on i386:
drivers/built-in.o: In function `xen_callback_vector':
(.text+0x1dc3cb): undefined reference to `first_system_vector'
drivers/built-in.o: In function
On Wed, Jun 26, 2013 at 7:15 PM, Greg Kroah-Hartman
wrote:
> On Wed, Jun 26, 2013 at 05:36:03PM +0200, Sedat Dilek wrote:
>> On Wed, Jun 26, 2013 at 5:32 PM, Greg Kroah-Hartman
>> wrote:
>> > On Wed, Jun 26, 2013 at 05:24:46PM +0200, Thomas Petazzoni wrote:
>> >> Dear Sedat Dilek,
>> >>
>> >> On
On Wed, Jun 26, 2013 at 05:36:03PM +0200, Sedat Dilek wrote:
> On Wed, Jun 26, 2013 at 5:32 PM, Greg Kroah-Hartman
> wrote:
> > On Wed, Jun 26, 2013 at 05:24:46PM +0200, Thomas Petazzoni wrote:
> >> Dear Sedat Dilek,
> >>
> >> On Wed, 26 Jun 2013 16:50:55 +0200, Sedat Dilek wrote:
> >>
> >> > [
Dear Greg Kroah-Hartman,
On Wed, 26 Jun 2013 08:32:36 -0700, Greg Kroah-Hartman wrote:
> > Ok. My understanding is that the misc device registered by
> > fs/fuse/dev.c:fuse_dev_init() makes the assumption that
> > file->private_data == NULL when a misc device is opened. But I'm not
> > sure to
On Wed, Jun 26, 2013 at 5:32 PM, Greg Kroah-Hartman
wrote:
> On Wed, Jun 26, 2013 at 05:24:46PM +0200, Thomas Petazzoni wrote:
>> Dear Sedat Dilek,
>>
>> On Wed, 26 Jun 2013 16:50:55 +0200, Sedat Dilek wrote:
>>
>> > [ TO/CC char-misc folks ]
>> >
>> > The CULPRIT commit [1] due to my
On Wed, Jun 26, 2013 at 05:24:46PM +0200, Thomas Petazzoni wrote:
> Dear Sedat Dilek,
>
> On Wed, 26 Jun 2013 16:50:55 +0200, Sedat Dilek wrote:
>
> > [ TO/CC char-misc folks ]
> >
> > The CULPRIT commit [1] due to my git-bisecting is:
> >
> > commit 585d98e00ba7a5e2abe65f7a1eff631cb612289b
>
On Wed, Jun 26, 2013 at 5:24 PM, Thomas Petazzoni
wrote:
> Dear Sedat Dilek,
>
> On Wed, 26 Jun 2013 16:50:55 +0200, Sedat Dilek wrote:
>
>> [ TO/CC char-misc folks ]
>>
>> The CULPRIT commit [1] due to my git-bisecting is:
>>
>> commit 585d98e00ba7a5e2abe65f7a1eff631cb612289b
>> "char: misc:
Dear Sedat Dilek,
On Wed, 26 Jun 2013 16:50:55 +0200, Sedat Dilek wrote:
> [ TO/CC char-misc folks ]
>
> The CULPRIT commit [1] due to my git-bisecting is:
>
> commit 585d98e00ba7a5e2abe65f7a1eff631cb612289b
> "char: misc: assign file->private_data in all cases"
>
> After reverting it, my
On Wed, Jun 26, 2013 at 11:48 AM, Sedat Dilek wrote:
> On Wed, Jun 26, 2013 at 10:06 AM, Stephen Rothwell
> wrote:
>> Hi all,
>>
>> Changes since 20130625:
>>
>> New tree: cpuinit
>>
>> The arm-mpidr tree gained a conflict against the arm tree.
>>
>> The net-next tree gained a conflict against
On Wed, Jun 26, 2013 at 11:48 AM, Sedat Dilek sedat.di...@gmail.com wrote:
On Wed, Jun 26, 2013 at 10:06 AM, Stephen Rothwell s...@canb.auug.org.au
wrote:
Hi all,
Changes since 20130625:
New tree: cpuinit
The arm-mpidr tree gained a conflict against the arm tree.
The net-next tree
Dear Sedat Dilek,
On Wed, 26 Jun 2013 16:50:55 +0200, Sedat Dilek wrote:
[ TO/CC char-misc folks ]
The CULPRIT commit [1] due to my git-bisecting is:
commit 585d98e00ba7a5e2abe65f7a1eff631cb612289b
char: misc: assign file-private_data in all cases
After reverting it, my system boots
On Wed, Jun 26, 2013 at 5:24 PM, Thomas Petazzoni
thomas.petazz...@free-electrons.com wrote:
Dear Sedat Dilek,
On Wed, 26 Jun 2013 16:50:55 +0200, Sedat Dilek wrote:
[ TO/CC char-misc folks ]
The CULPRIT commit [1] due to my git-bisecting is:
commit
On Wed, Jun 26, 2013 at 05:24:46PM +0200, Thomas Petazzoni wrote:
Dear Sedat Dilek,
On Wed, 26 Jun 2013 16:50:55 +0200, Sedat Dilek wrote:
[ TO/CC char-misc folks ]
The CULPRIT commit [1] due to my git-bisecting is:
commit 585d98e00ba7a5e2abe65f7a1eff631cb612289b
char: misc:
On Wed, Jun 26, 2013 at 5:32 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Wed, Jun 26, 2013 at 05:24:46PM +0200, Thomas Petazzoni wrote:
Dear Sedat Dilek,
On Wed, 26 Jun 2013 16:50:55 +0200, Sedat Dilek wrote:
[ TO/CC char-misc folks ]
The CULPRIT commit [1] due to my
Dear Greg Kroah-Hartman,
On Wed, 26 Jun 2013 08:32:36 -0700, Greg Kroah-Hartman wrote:
Ok. My understanding is that the misc device registered by
fs/fuse/dev.c:fuse_dev_init() makes the assumption that
file-private_data == NULL when a misc device is opened. But I'm not
sure to fully
On Wed, Jun 26, 2013 at 05:36:03PM +0200, Sedat Dilek wrote:
On Wed, Jun 26, 2013 at 5:32 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Wed, Jun 26, 2013 at 05:24:46PM +0200, Thomas Petazzoni wrote:
Dear Sedat Dilek,
On Wed, 26 Jun 2013 16:50:55 +0200, Sedat Dilek wrote:
On Wed, Jun 26, 2013 at 7:15 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Wed, Jun 26, 2013 at 05:36:03PM +0200, Sedat Dilek wrote:
On Wed, Jun 26, 2013 at 5:32 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Wed, Jun 26, 2013 at 05:24:46PM +0200, Thomas Petazzoni
On 06/26/13 01:06, Stephen Rothwell wrote:
Hi all,
Changes since 20130625:
CONFIG_SMP is not set
CONFIG_X86_UP_APIC is not set
on i386:
drivers/built-in.o: In function `xen_callback_vector':
(.text+0x1dc3cb): undefined reference to `first_system_vector'
drivers/built-in.o: In function
On Wed, Jun 26, 2013 at 11:48:58AM -0700, Randy Dunlap wrote:
On 06/26/13 01:06, Stephen Rothwell wrote:
Hi all,
Changes since 20130625:
CONFIG_SMP is not set
CONFIG_X86_UP_APIC is not set
That is new. Any thoughts of which patch might be the culprit?
What are the other config
48 matches
Mail list logo