| Message ID | 156699905611.5321.15444519862547054670.tip-bot2@tip-bot2 (mailing list archive) |
|---|---|
| State | Mainlined |
| Commit | f7b15c74cffd760ec9959078982d8268a38456c4 |
| Headers | show |
| Series | [tip:,x86/vmware] input/vmmouse: Update the backdoor call with support for new instructions | expand |
On Fri, Aug 30, 2019 at 12:01:48AM +0800, kbuild test robot wrote: > Hi tip-bot2, > > Thank you for the patch! Yet something to improve: > > [auto build test ERROR on linus/master] > [cannot apply to v5.3-rc6 next-20190829] > [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] Yes, it looks like it. > url: https://github.com/0day-ci/linux/commits/tip-bot2-for-Thomas-Hellstrom/input-vmmouse-Update-the-backdoor-call-with-support-for-new-instructions/20190829-205315 This patch is part of a series which are here: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=x86/vmware so you need the patches before it. I don't know what you guys are doing to track patches but if you really wanna test trees, I'd suggest simply testing TIP's tip/master branch which gets redone on a daily basis instead of testing patches in the tip-bot{,2} notification mails. Thx.
On Thu, Aug 29, 2019 at 06:33:53PM +0200, Borislav Petkov wrote: > On Fri, Aug 30, 2019 at 12:01:48AM +0800, kbuild test robot wrote: > > Hi tip-bot2, > > > > Thank you for the patch! Yet something to improve: > > > > [auto build test ERROR on linus/master] > > [cannot apply to v5.3-rc6 next-20190829] > > [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] > > Yes, it looks like it. > > > url: https://github.com/0day-ci/linux/commits/tip-bot2-for-Thomas-Hellstrom/input-vmmouse-Update-the-backdoor-call-with-support-for-new-instructions/20190829-205315 > > This patch is part of a series which are here: > > https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=x86/vmware > > so you need the patches before it. > > I don't know what you guys are doing to track patches but if you really > wanna test trees, I'd suggest simply testing TIP's tip/master branch > which gets redone on a daily basis instead of testing patches in the > tip-bot{,2} notification mails. Thanks Boris for the input. Besides the repo monitoring, we also check the patches in mailing lists, and try to apply patch to a suitable base. Do you think we can skip the mailing list of tip-bot{,2}? > > Thx. > > -- > Regards/Gruss, > Boris. > > SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 247165, AG München > _______________________________________________ > kbuild-all mailing list > kbuild-all@lists.01.org > https://lists.01.org/mailman/listinfo/kbuild-all
Philip, On Fri, 30 Aug 2019, Philip Li wrote: > > wanna test trees, I'd suggest simply testing TIP's tip/master branch > > which gets redone on a daily basis instead of testing patches in the > > tip-bot{,2} notification mails. > > Thanks Boris for the input. Besides the repo monitoring, we also check the patches > in mailing lists, and try to apply patch to a suitable base. Do you think we can > skip the mailing list of tip-bot{,2}? As I just explained in a reply to another random build failure caused by this. tip-bot2 is a notification mechanism to let people know that a particular patch has been merged into one of the tip tree branches. These mails are also properly threaded most of the time and reply to the patch which was sent to the mailing list. So yes, randomly picking patches from tip-bot2 is not useful at all. The mails contain the information to which tip branch the patch has been applied, so the only useful information for your bot is to select the branch which got the new patches and start testing on that one. Thanks, tglx
On Fri, Aug 30, 2019 at 08:06:27AM +0200, Thomas Gleixner wrote: > Philip, > > On Fri, 30 Aug 2019, Philip Li wrote: > > > > wanna test trees, I'd suggest simply testing TIP's tip/master branch > > > which gets redone on a daily basis instead of testing patches in the > > > tip-bot{,2} notification mails. > > > > Thanks Boris for the input. Besides the repo monitoring, we also check the patches > > in mailing lists, and try to apply patch to a suitable base. Do you think we can > > skip the mailing list of tip-bot{,2}? > > As I just explained in a reply to another random build failure caused by this. > > tip-bot2 is a notification mechanism to let people know that a particular > patch has been merged into one of the tip tree branches. These mails are > also properly threaded most of the time and reply to the patch which was > sent to the mailing list. > > So yes, randomly picking patches from tip-bot2 is not useful at all. The > mails contain the information to which tip branch the patch has been > applied, so the only useful information for your bot is to select the > branch which got the new patches and start testing on that one. thanks for your patience. I just realize we actually block tip-bot, but not tip-bot2. I will update the logic to avoid this issue, and we will keep monitor for a while to fix new issue if any. > > Thanks, > > tglx
On Fri, Aug 30, 2019 at 02:20:53PM +0800, Philip Li wrote: > On Fri, Aug 30, 2019 at 08:06:27AM +0200, Thomas Gleixner wrote: > > Philip, > > > > On Fri, 30 Aug 2019, Philip Li wrote: > > > > > > wanna test trees, I'd suggest simply testing TIP's tip/master branch > > > > which gets redone on a daily basis instead of testing patches in the > > > > tip-bot{,2} notification mails. > > > > > > Thanks Boris for the input. Besides the repo monitoring, we also check the patches > > > in mailing lists, and try to apply patch to a suitable base. Do you think we can > > > skip the mailing list of tip-bot{,2}? > > > > As I just explained in a reply to another random build failure caused by this. > > > > tip-bot2 is a notification mechanism to let people know that a particular > > patch has been merged into one of the tip tree branches. These mails are > > also properly threaded most of the time and reply to the patch which was > > sent to the mailing list. > > > > So yes, randomly picking patches from tip-bot2 is not useful at all. The > > mails contain the information to which tip branch the patch has been > > applied, so the only useful information for your bot is to select the > > branch which got the new patches and start testing on that one. > thanks for your patience. I just realize we actually block tip-bot, but > not tip-bot2. I will update the logic to avoid this issue, and we will > keep monitor for a while to fix new issue if any. BTW: the related service need some time to be upgraded after code change, some already fetched patches will continue sending out noisy mails until they are consumed. Sorry about this. > > > > > Thanks, > > > > tglx
On Fri, 30 Aug 2019, Philip Li wrote: > On Fri, Aug 30, 2019 at 02:20:53PM +0800, Philip Li wrote: > > thanks for your patience. I just realize we actually block tip-bot, but > > not tip-bot2. I will update the logic to avoid this issue, and we will > > keep monitor for a while to fix new issue if any. > > BTW: the related service need some time to be upgraded after code change, > some already fetched patches will continue sending out noisy mails until > they are consumed. Sorry about this. All good. I'll just redirect them to /dev/null. Thanks, tglx
On Fri, Aug 30, 2019 at 02:20:53PM +0800, Philip Li wrote: > thanks for your patience. I just realize we actually block tip-bot, but > not tip-bot2. I will update the logic to avoid this issue, and we will > keep monitor for a while to fix new issue if any. ... and just to reiterate: it would be a *lot-lot* more useful if you guys tested the single tip branches or the combined tip/master on a daily basis as that is the x86 queue that goes to Linus eventually. That is, if you do not test it already. But we don't get any "we tested this branch" email so I'm thinking you don't... Thx.
On Fri, Aug 30, 2019 at 10:06:50AM +0200, Borislav Petkov wrote: > On Fri, Aug 30, 2019 at 02:20:53PM +0800, Philip Li wrote: > > thanks for your patience. I just realize we actually block tip-bot, but > > not tip-bot2. I will update the logic to avoid this issue, and we will > > keep monitor for a while to fix new issue if any. > > ... and just to reiterate: it would be a *lot-lot* more useful if you > guys tested the single tip branches or the combined tip/master on a > daily basis as that is the x86 queue that goes to Linus eventually. That yes, we monitor the repo pub/scm/linux/kernel/git/tip/tip.git, and will send build status of head (like BUILD SUCCESS or REGRESSION), also provide bisect report of unique error for first bad commit. > is, if you do not test it already. But we don't get any "we tested this > branch" email so I'm thinking you don't... > > Thx. > > -- > Regards/Gruss, > Boris. > > Good mailing practices for 400: avoid top-posting and trim the reply.
On Fri, Aug 30, 2019 at 10:36:45PM +0800, Philip Li wrote: > yes, we monitor the repo pub/scm/linux/kernel/git/tip/tip.git, and will > send build status of head ... and what you call "head" is the "master" branch on that repo, right? Just making sure you got that right. > (like BUILD SUCCESS or REGRESSION), also provide bisect report of > unique error for first bad commit. Perfect! Thx.
On Fri, Aug 30, 2019 at 04:46:28PM +0200, Borislav Petkov wrote: > On Fri, Aug 30, 2019 at 10:36:45PM +0800, Philip Li wrote: > > yes, we monitor the repo pub/scm/linux/kernel/git/tip/tip.git, and will > > send build status of head > > ... and what you call "head" is the "master" branch on that repo, right? Hi Boris, you are right. It is the head of monitored branch, here master branch is one of the branches on this repo that we monitor. Early on, there's requirement to blacklist a few branches, which is configured as below blacklist_branch: auto-.*|tmp-.*|base-.*|test.*|.*-for-linus Except the blacklist branches, we will monitor all other branches. We also support pull request to update the configuration or email us to update. Refer to https://github.com/intel/lkp-tests/blob/master/repo/linux/tip. Thanks > Just making sure you got that right. > > > (like BUILD SUCCESS or REGRESSION), also provide bisect report of > > unique error for first bad commit. > > Perfect! > > Thx. > > -- > Regards/Gruss, > Boris. > > Good mailing practices for 400: avoid top-posting and trim the reply.
On Fri, Aug 30, 2019 at 11:00:02PM +0800, Philip Li wrote: > Early on, there's requirement to blacklist a few branches, which is configured > as below > blacklist_branch: auto-.*|tmp-.*|base-.*|test.*|.*-for-linus Looks about right. > Except the blacklist branches, we will monitor all other branches. Ok, good to know. Just as an optimization to your workflow, in case you're interested: the tip/master branch merges all tip branches so if you're trying to prioritize which branches to test first due to resource constraints, I'd go with tip/master first and then, when I have free cycles, I'd do the topic branches. Just as an idea... > We also support pull request to update the > configuration or email us to update. Refer to > https://github.com/intel/lkp-tests/blob/master/repo/linux/tip. Ok, cool. I'll talk to tglx about it and might even send you a pull request. Thx.
On Fri, Aug 30, 2019 at 11:00:02PM +0800, Philip Li wrote: > On Fri, Aug 30, 2019 at 04:46:28PM +0200, Borislav Petkov wrote: > > On Fri, Aug 30, 2019 at 10:36:45PM +0800, Philip Li wrote: > > > yes, we monitor the repo pub/scm/linux/kernel/git/tip/tip.git, and will > > > send build status of head > > > > ... and what you call "head" is the "master" branch on that repo, right? > Hi Boris, you are right. It is the head of monitored branch, here master branch is > one of the branches on this repo that we monitor. > > Early on, there's requirement to blacklist a few branches, which is configured > as below > blacklist_branch: auto-.*|tmp-.*|base-.*|test.*|.*-for-linus > > Except the blacklist branches, we will monitor all other branches. We also > support pull request to update the configuration or email us to update. > Refer to https://github.com/intel/lkp-tests/blob/master/repo/linux/tip. > > Thanks > > > Just making sure you got that right. > > > > > (like BUILD SUCCESS or REGRESSION), also provide bisect report of > > > unique error for first bad commit. > > > > Perfect! hi Boris, for the build status notification, we currently send to below address, is it still valid? If not, can you suggest one for us? tip build status <tipbuild@zytor.com> > > > > Thx. > > > > -- > > Regards/Gruss, > > Boris. > > > > Good mailing practices for 400: avoid top-posting and trim the reply.
On Fri, Aug 30, 2019 at 05:06:53PM +0200, Borislav Petkov wrote: > On Fri, Aug 30, 2019 at 11:00:02PM +0800, Philip Li wrote: > > Early on, there's requirement to blacklist a few branches, which is configured > > as below > > blacklist_branch: auto-.*|tmp-.*|base-.*|test.*|.*-for-linus > > Looks about right. > > > Except the blacklist branches, we will monitor all other branches. > > Ok, good to know. Just as an optimization to your workflow, in case > you're interested: the tip/master branch merges all tip branches so if > you're trying to prioritize which branches to test first due to resource > constraints, I'd go with tip/master first and then, when I have free > cycles, I'd do the topic branches. thanks a lot for the advice. Meanwhile, the internal logic merges branches to test once to speed up, most of time, more branches will not increase the build testing workload. Of course, for the non merged branches, we need test individually, and we will take this information into consideration to add to our TODO. > > Just as an idea... > > > We also support pull request to update the > > configuration or email us to update. Refer to > > https://github.com/intel/lkp-tests/blob/master/repo/linux/tip. > > Ok, cool. I'll talk to tglx about it and might even send you a pull > request. > > Thx. > > -- > Regards/Gruss, > Boris. > > Good mailing practices for 400: avoid top-posting and trim the reply.
On Fri, Aug 30, 2019 at 11:08:56PM +0800, Philip Li wrote: > hi Boris, for the build status notification, we currently send to below > address, is it still valid? If not, can you suggest one for us? Sure, here's an update patch ontop of your master branch: --- From: Borislav Petkov <bp@suse.de> Date: Fri, 30 Aug 2019 21:33:29 +0200 Subject: [PATCH] repo/linux/tip: Update tip tree contact information Replace hpa with Borislav and change contact mail address. Signed-off-by: Borislav Petkov <bp@suse.de> --- repo/linux/tip | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/repo/linux/tip b/repo/linux/tip index 4fc5d88176fd..96a7dec66f97 100644 --- a/repo/linux/tip +++ b/repo/linux/tip @@ -2,11 +2,11 @@ url: https://kernel.googlesource.com/pub/scm/linux/kernel/git/tip/tip.git integration_testing_branches: auto-latest mail_cc: - linux-kernel@vger.kernel.org -- tipbuild@zytor.com +- x86@kernel.org owner: - Ingo Molnar <mingo@kernel.org> -- H. Peter Anvin <hpa@zytor.com> - Thomas Gleixner <tglx@linutronix.de> +- Borislav Petkov <bp@suse.de> subsystems: - x86 - fpu @@ -16,4 +16,4 @@ subsystems: - locking blacklist_branch: auto-.*|tmp-.*|base-.*|test.*|.*-for-linus notify_build_success_branch: .* -build_success_mail_to: tip build status <tipbuild@zytor.com> +build_success_mail_to: x86-ml <x86@kernel.org>
On Fri, Aug 30, 2019 at 09:35:57PM +0200, Borislav Petkov wrote: > On Fri, Aug 30, 2019 at 11:08:56PM +0800, Philip Li wrote: > > hi Boris, for the build status notification, we currently send to below > > address, is it still valid? If not, can you suggest one for us? > > Sure, here's an update patch ontop of your master branch: Thanks Boris, it is applied, and will take effect soon. > > --- > From: Borislav Petkov <bp@suse.de> > Date: Fri, 30 Aug 2019 21:33:29 +0200 > Subject: [PATCH] repo/linux/tip: Update tip tree contact information > > Replace hpa with Borislav and change contact mail address. > > Signed-off-by: Borislav Petkov <bp@suse.de> > --- > repo/linux/tip | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/repo/linux/tip b/repo/linux/tip > index 4fc5d88176fd..96a7dec66f97 100644 > --- a/repo/linux/tip > +++ b/repo/linux/tip > @@ -2,11 +2,11 @@ url: https://kernel.googlesource.com/pub/scm/linux/kernel/git/tip/tip.git > integration_testing_branches: auto-latest > mail_cc: > - linux-kernel@vger.kernel.org > -- tipbuild@zytor.com > +- x86@kernel.org > owner: > - Ingo Molnar <mingo@kernel.org> > -- H. Peter Anvin <hpa@zytor.com> > - Thomas Gleixner <tglx@linutronix.de> > +- Borislav Petkov <bp@suse.de> > subsystems: > - x86 > - fpu > @@ -16,4 +16,4 @@ subsystems: > - locking > blacklist_branch: auto-.*|tmp-.*|base-.*|test.*|.*-for-linus > notify_build_success_branch: .* > -build_success_mail_to: tip build status <tipbuild@zytor.com> > +build_success_mail_to: x86-ml <x86@kernel.org> > -- > 2.21.0 > > Thx. > > -- > Regards/Gruss, > Boris. > > Good mailing practices for 400: avoid top-posting and trim the reply.
On Mon, Sep 02, 2019 at 09:13:42AM +0800, Philip Li wrote:
> Thanks Boris, it is applied, and will take effect soon.
Seems to has taken effect. I got the first build report.
Thx!
On Mon, Sep 02, 2019 at 11:36:51AM +0200, Borislav Petkov wrote: > On Mon, Sep 02, 2019 at 09:13:42AM +0800, Philip Li wrote: > > Thanks Boris, it is applied, and will take effect soon. > > Seems to has taken effect. I got the first build report. thanks for the info, Boris, glad to know this. > > Thx! > > -- > Regards/Gruss, > Boris. > > Good mailing practices for 400: avoid top-posting and trim the reply.
diff --git a/drivers/input/mouse/vmmouse.c b/drivers/input/mouse/vmmouse.c index 871e5b5..148245c 100644 --- a/drivers/input/mouse/vmmouse.c +++ b/drivers/input/mouse/vmmouse.c @@ -16,12 +16,12 @@ #include <linux/slab.h> #include <linux/module.h> #include <asm/hypervisor.h> +#include <asm/vmware.h> #include "psmouse.h" #include "vmmouse.h" #define VMMOUSE_PROTO_MAGIC 0x564D5868U -#define VMMOUSE_PROTO_PORT 0x5658 /* * Main commands supported by the vmmouse hypervisor port. @@ -84,7 +84,7 @@ struct vmmouse_data { #define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4) \ ({ \ unsigned long __dummy1, __dummy2; \ - __asm__ __volatile__ ("inl %%dx" : \ + __asm__ __volatile__ (VMWARE_HYPERCALL : \ "=a"(out1), \ "=b"(out2), \ "=c"(out3), \ @@ -94,7 +94,7 @@ struct vmmouse_data { "a"(VMMOUSE_PROTO_MAGIC), \ "b"(in1), \ "c"(VMMOUSE_PROTO_CMD_##cmd), \ - "d"(VMMOUSE_PROTO_PORT) : \ + "d"(0) : \ "memory"); \ })