Re: [PATCH 01/15] EDAC: make device_type const
On Sat, Aug 19, 2017 at 01:52:12PM +0530, Bhumika Goyal wrote: > Make these const as they are only stored in the type field of a device > structure, which is const. > Done using Coccinelle. > > Signed-off-by: Bhumika Goyal > --- > drivers/edac/edac_mc_sysfs.c | 8 > drivers/edac/i7core_edac.c | 4 ++-- > 2 files changed, 6 insertions(+), 6 deletions(-) Applied, thanks. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH v3 4/8] x86: stop exporting msr-index.h to userland
On Fri, Jan 13, 2017 at 05:08:34PM +0100, Nicolas Dichtel wrote: > Le 13/01/2017 à 16:43, David Howells a écrit : > >> -header-y += msr-index.h > > > > I see it on my desktop as /usr/include/asm/msr-index.h and it's been there > > at > > least four years - and as such it's part of the UAPI. I don't think you can > > remove it unless you can guarantee there are no userspace users. > I keep it in the v2 of the series, but the maintainer, Borislav Petkov, asks > me > to un-export it. > > I will follow the maintainer decision. I'm not the maintainer. I simply think that exporting that file was wrong because it if we change something in it, we will break userspace. And that should not happen - if userspace needs MSRs, it should do its own defines. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/7] x86: put msr-index.h in uapi
On Fri, Jan 06, 2017 at 10:43:56AM +0100, Nicolas Dichtel wrote: > This header file is exported, thus move it to uapi. It should rather not be exported - please remove it from arch/x86/include/uapi/asm/Kbuild instead. Thanks. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [x86/mm/pat, drivers/media/ivtv] WARNING: CPU: 0 PID: 1 at drivers/media/pci/ivtv/ivtvfb.c:1270 ivtvfb_init()
On Mon, Jun 22, 2015 at 03:01:38AM +0200, Luis R. Rodriguez wrote: > We can certainly replace the WARN() with pr_warn(), I don't see > how its confusing though as its a run time real issue. Either > way whatever you recommend is fine by me. Yeah, it confused the 0day robot at least. :-) But maybe because it cannot really read. But I've experienced cases where people don't read too, see *a* splat and raise the alarm. So yeah, I think a simple pr_warn would be much better. Thanks. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line "unsubscribe linux-media" in
Re: [x86/mm/pat, drivers/media/ivtv] WARNING: CPU: 0 PID: 1 at drivers/media/pci/ivtv/ivtvfb.c:1270 ivtvfb_init()
On Sun, Jun 21, 2015 at 10:23:48PM +0200, Luis R. Rodriguez wrote: > Nope, well the driver requires huge amounts of work to work with PAT, > that work will likely never be done, so hence the warning. Its our > compromise as only 2 drivers will live on Linux like this and they are > both old and rare. Hmm, so wasn't the possibility discussed to fail loading instead and issue a single-line pr_warn() when PAT is enabled? Those big WARN() splats will only confuse people... -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line "unsubscribe linux-media" in
Re: [x86/mm/pat, drivers/media/ivtv] WARNING: CPU: 0 PID: 1 at drivers/media/pci/ivtv/ivtvfb.c:1270 ivtvfb_init()
On Sat, Jun 20, 2015 at 03:17:56PM +0800, Fengguang Wu wrote: > Greetings, > > 0day kernel testing robot got the below dmesg and the first bad commit is > > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master > > commit 1bf1735b478008c30acaff18ec6f4a3ff211c28a > Author: Luis R. Rodriguez > AuthorDate: Mon Jun 15 10:28:16 2015 +0200 > Commit: Ingo Molnar > CommitDate: Thu Jun 18 11:23:41 2015 +0200 > > x86/mm/pat, drivers/media/ivtv: Use arch_phys_wc_add() and require PAT > disabled ... > [ 12.956506] ivtv: Start initialization, version 1.4.3 > [ 12.958238] ivtv: End initialization > [ 12.959438] [ cut here ] > [ 12.974076] WARNING: CPU: 0 PID: 1 at drivers/media/pci/ivtv/ivtvfb.c:1270 > ivtvfb_init+0x32/0xa3() > [ 12.978017] ivtvfb needs PAT disabled, boot with nopat kernel parameter Warning says it all. You need to boot with "nopat". Apparently, those devices are very seldom now and users should boot with "nopat". Luis, what is the plan, is this driver supposed to be converted to reserve_memtype(..., _PAGE_CACHE_MODE_WC, ...) at some point? Thanks. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line "unsubscribe linux-media" in
Re: [PATCH v6 2/3] IB/ipath: add counting for MTRR
On Thu, Jun 11, 2015 at 10:50:01AM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> There is no good reason not to, we eventually delete it as well.
>
> Cc: Toshi Kani
> Cc: Roland Dreier
> Cc: Sean Hefty
> Cc: Hal Rosenstock
> Cc: Suresh Siddha
> Cc: Ingo Molnar
> Cc: Thomas Gleixner
> Cc: Juergen Gross
> Cc: Daniel Vetter
> Cc: Andy Lutomirski
> Cc: Dave Airlie
> Cc: Antonino Daplas
> Cc: Jean-Christophe Plagniol-Villard
> Cc: Tomi Valkeinen
> Cc: infinip...@intel.com
> Cc: linux-r...@vger.kernel.org
> Cc: linux-fb...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Luis R. Rodriguez
> ---
> drivers/infiniband/hw/ipath/ipath_wc_x86_64.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
> b/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
> index 4ad0b93..70c1f3a 100644
> --- a/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
> +++ b/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
> @@ -127,7 +127,7 @@ int ipath_enable_wc(struct ipath_devdata *dd)
> "(addr %llx, len=0x%llx)\n",
> (unsigned long long) pioaddr,
> (unsigned long long) piolen);
> - cookie = mtrr_add(pioaddr, piolen, MTRR_TYPE_WRCOMB, 0);
> + cookie = mtrr_add(pioaddr, piolen, MTRR_TYPE_WRCOMB, 1);
> if (cookie < 0) {
> {
> dev_info(&dd->pcidev->dev,
> --
Doug, ack?
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH bp] EDAC, mce_amd_inj: inj_type can be static
On Fri, Jun 05, 2015 at 07:24:26PM +0800, kbuild test robot wrote:
>
> Signed-off-by: Fengguang Wu
> ---
> mce_amd_inj.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/edac/mce_amd_inj.c b/drivers/edac/mce_amd_inj.c
> index 2a0c829..46a6b0e 100644
> --- a/drivers/edac/mce_amd_inj.c
> +++ b/drivers/edac/mce_amd_inj.c
> @@ -44,7 +44,7 @@ static const char * const flags_options[] = {
> };
>
> /* Set default injection to SW_INJ */
> -enum injection_type inj_type = SW_INJ;
> +static enum injection_type inj_type = SW_INJ;
>
> #define MCE_INJECT_SET(reg) \
> static int inj_##reg##_set(void *data, u64 val)
> \
Thanks kbuild test robot, applied!
:-D
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7 linux-next] drivers: remove deprecated IRQF_DISABLED
On Mon, Oct 06, 2014 at 08:33:00PM +0200, Fabian Frederick wrote: > You're right, I guess we can forget this patchset. > I didn't see it was already done. (nothing in linux-next yet). Not the whole patchset - I was replying only to your two patches touching code in drivers/edac/. I don't know about the rest but yeah, checking linux-next is always a good idea. Also, did you CC the proper maintainers for the rest of your patches? If not, do that and see what they have to say. HTH. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7 linux-next] drivers: remove deprecated IRQF_DISABLED
On Mon, Oct 06, 2014 at 05:35:47PM +0200, Fabian Frederick wrote: > This small patchset removes IRQF_DISABLED from drivers branch. > > See include/linux/interrupt.h: > "This flag is a NOOP and scheduled to be removed" > > Note: (cross)compiled but untested. > > Fabian Frederick (7): > mv64x60_edac: remove deprecated IRQF_DISABLED > ppc4xx_edac: remove deprecated IRQF_DISABLED For the EDAC bits already applied Michael's patch: https://lkml.kernel.org/r/1412159043-7348-1-git-send-email-michael.opdenac...@free-electrons.com -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WARNING: at drivers/media/v4l2-core/videobuf2-core.c:2065 vb2_queue_init+0x74/0x142()
On Fri, May 10, 2013 at 02:06:50PM +0200, Hans Verkuil wrote: > Can you try this patch? This should fix it. Yep, it does. Tested-by: Borislav Petkov > diff --git a/drivers/media/parport/bw-qcam.c b/drivers/media/parport/bw-qcam.c > index 06231b8..d12bd33 100644 > --- a/drivers/media/parport/bw-qcam.c > +++ b/drivers/media/parport/bw-qcam.c > @@ -687,6 +687,7 @@ static int buffer_finish(struct vb2_buffer *vb) > > parport_release(qcam->pdev); > mutex_unlock(&qcam->lock); > + v4l2_get_timestamp(&vb->v4l2_buf.timestamp); > if (len != size) > vb->state = VB2_BUF_STATE_ERROR; > vb2_set_plane_payload(vb, 0, len); > @@ -964,6 +965,7 @@ static struct qcam *qcam_init(struct parport *port) > q->drv_priv = qcam; > q->ops = &qcam_video_qops; > q->mem_ops = &vb2_vmalloc_memops; > + q->timestamp_type = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC; However, just FYI: I do trigger the warning in a guest and not on the real hardware. So I can't really confirm whether _MONOTONIC is the proper timestamp type or not. But it looks like you know what you're doing. :-) Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: at drivers/media/v4l2-core/videobuf2-core.c:2065 vb2_queue_init+0x74/0x142()
This one looks legit: bw-qcam.c doesn't set q->timestamp_type. [ 146.989016] Colour QuickCam for Video4Linux v0.06 [ 147.713065] [ cut here ] [ 147.928854] WARNING: at drivers/media/v4l2-core/videobuf2-core.c:2065 vb2_queue_init+0x74/0x142() [ 148.364433] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.9.0-12947-g0f99ebe5052a #1 [ 148.799135] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007 [ 149.017598] 8239cab3 88007b789d48 81d81cb0 88007b789d88 [ 149.465524] 810943a8 88007b789d88 880079a7a700 [ 149.909985] 880079a7a068 880079a7a608 8800798d1c00 88007b789d98 [ 150.345653] Call Trace: [ 150.550444] [] dump_stack+0x19/0x1b [ 150.756860] [] warn_slowpath_common+0x62/0x7b [ 150.962012] [] warn_slowpath_null+0x1a/0x1e [ 151.160574] [] vb2_queue_init+0x74/0x142 [ 151.354795] [] bwqcam_attach+0x1e0/0x54a [ 151.543644] [] parport_register_driver+0x2e/0x6d [ 151.727651] [] ? cqcam_init+0x20/0x20 [ 151.906958] [] init_bw_qcams+0x10/0x12 [ 152.084031] [] do_one_initcall+0x7b/0x116 [ 152.262088] [] kernel_init_freeable+0x160/0x1f2 [ 152.441466] [] ? do_early_param+0x8c/0x8c [ 152.619998] [] ? rest_init+0xdf/0xdf [ 152.797458] [] kernel_init+0xe/0xdb [ 152.970650] [] ret_from_fork+0x7c/0xb0 [ 153.140434] [] ? rest_init+0xdf/0xdf [ 153.305520] ---[ end trace a72f2983de4c60b5 ]--- [ 154.459479] No Quickcam found on port parport0 [ 154.613448] Quickcam detection counter: 0 -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: Re: Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On Sun, Oct 21, 2012 at 07:49:01PM +, Artem S. Tashkinov wrote: > I ran it this way: while :; do dmesg -c; done | scat /dev/sda11 (yes, > straight to a hdd partition to eliminate a FS cache) Well, I'm no fs guy but this should still go through the buffer cache. I think the O_SYNC flag makes sure it all lands on the partition in time. Oh well, it doesn't matter. > Don't judge me harshly - I'm not a programmer. If you wrote that and you're not a programmer, it certainly looks cool, good job!. [ Btw, don't forget to free(buffer) at the end. ] Also, there was a patchset recently which added a blockconsole method to the kernel with which you can do something like that in a generic way. Back to the issue at hand: it looks like ehci_hcd is causing some list corruptions, maybe coming from the uvcvideo or whatever. I think the usb people will have a better idea. Btw, is there any particular reason you're running a 32-bit kernel? Thanks. -- Regards/Gruss, Boris. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On Sun, Oct 21, 2012 at 11:59:36AM +, Artem S. Tashkinov wrote: > http://imageshack.us/a/img685/9452/panicz.jpg > > list_del corruption. prev->next should be ... but was ... Btw, this is one of the debug options I told you to enable. > I cannot show you more as I have no serial console to use :( and the kernel > doesn't have enough time to push error messages to rsyslog and fsync > /var/log/messages I already told you how to catch that oops: boot with "pause_on_oops=600" on the kernel command line and photograph the screen when the first oops happens. This'll show us where the problem begins. -- Regards/Gruss, Boris. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On Sun, Oct 21, 2012 at 01:57:21AM +, Artem S. Tashkinov wrote: > The freeze happens on my *host* Linux PC. For an experiment I decided > to check if I could reproduce the freeze under a virtual machine - it > turns out the Linux kernel running under it also freezes. I know that - but a freeze != oops - at least not necessarily. Which means it could very well be a different issue now that vbox is gone. Or, it could be the same issue with different incarnations: with vbox you get the corruptions and without it, you get the freezes. I'm assuming you do the same flash player thing in both cases? Here's a crazy idea: can you try to reproduce it in KVM? Thanks. -- Regards/Gruss, Boris. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
> [ 301.111289] usb 1-1: adding 1-1:1.3 (config #1, interface 3) > [ 301.131207] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us] > [ 301.137066] usb 1-1: unlink qh16-0001/f48d64c0 start 2 [1/0 us] > [ 301.156451] ehci_hcd :00:1f.5: reused qh f48d64c0 schedule > [ 301.158310] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us] > [ 301.160238] usb 1-1: unlink qh16-0001/f48d64c0 start 2 [1/0 us] > [ 301.196606] set resolution quirk: cval->res = 384 > [ 371.309569] e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow > Control: RX > [ 390.729568] ehci_hcd :00:1f.5: reused qh f48d64c0 schedule > f5ade900 2296555[ 390.730023] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 > us] > 437 S Ii:1:003:7[ 390.736394] usb 1-1: unlink qh16-0001/f48d64c0 start 2 > [1/0 us] > -115:128 16 < > f5ade900 2296566256 C Ii:1:003:7 -2:128 0 > [ 391.100896] ehci_hcd :00:1f.5: reused qh f48d64c0 schedule > [ 391.103188] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us] > f5ade900 2296926929 S Ii:1:003:7[ 391.104889] usb 1-1: unlink > qh16-0001/f48d64c0 start 2 [1/0 us] > -115:128 16 < > f5ade900 2296937889 C Ii:1:003:7 -2:128 0 > f5272300 2310382508 S Co:1:003:0 s 01 0b 0004 0001 0 > f5272300 2310407888 C Co:1:003:0 0 0 > f5272300 2310408051 S Co:1:003:0 s 22 01 0100 0086 0003 3 = 80bb00 > f5272300 2310412456 C Co:1:003:0 0 3 > > f5272300 2310412521 S Ci:1:003:0 s a2 81 0100 0086 0003 3 < > f5272300 2310415909 C Ci:1:003:0 0 0 > f5272300 2310418133 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 < > f5272600 2310418219 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 < > f52720c0 2310418239 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 < > f5272a80 2310418247 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 < > f5272480 2310418256 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 < > f52723c0 2310418264 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 < > f5272d80 2310418272 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 < > f5272b40 2310418280 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 < > > Hard freeze with 100% CPU usage at this point as if some driver got into an > infinite loop or something. > > All debug options from https://lkml.org/lkml/2012/10/20/116 are enabled, but > serial console is empty. > > Best wishes, > > Artem > > > On Oct 21, 2012, Borislav Petkov wrote: > > > I don't think that's the problem - I rather suspect the fact that he's > > using virtualbox which is causing random corruptions by writing to > > arbitrary locations. > > > > > > > > please remove virtualbox completely from your system, rebuild the kernel > > and make sure the virtualbox kernel modules don't get loaded - simply > > delete them so that they are completely gone; *and* *then* retest again. > > -- Regards/Gruss, Boris. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
