[PATCH 1/1] revert commit 2c1f6951a8 videobuf2-v4l2

since kernel 4.5.3 a severe bug has been introduced with commit 2c1f6951a8a82e6de0d82b1158b5e493fc6c54ab ( [media] videobuf2-v4l2: Verify planes array in buffer dequeueing ), a system freeze will occur with TV cards ( DVB-T ), for example with "leadtek winfast DTV1000T", "leadtek winfast DTV1800H"

[PATCH 4.5 1/1] revert commit 2c1f6951a8 videobuf2-v4l2

since kernel 4.5.3 a severe bug has been introduced with commit 2c1f6951a8a82e6de0d82b1158b5e493fc6c54ab ( [media] videobuf2-v4l2: Verify planes array in buffer dequeueing ), a system freeze will occur with TV cards ( DVB-T ), for example with "leadtek winfast DTV1000T", "leadtek winfast DTV1800H"

RSS calculation in the 3.X Kernel

kernel's idea of my RSS far exceeds my idea. I'm not on the Linux Developers mailing list, so please CC me in any reply. Thanks for your time and consideration, David Barto ba...@cambrigesemantics.com

Re: [PATCH] PCI: Add disabling pm async quirk for JMicron chips

> Why is this being done through pci quirks? e6b7e41cdd8 implements the > same quirk in the respective drivers. What's the difference here? > > Thanks. > the difference is that the commit e6b7e41cdd8 "ata: Disabling the async PM for JMicron chip 363/361" doesn't work with my JMicron 363/368, b

Re: BUG in scsi_lib.c due to a bad commit

JMicron pcie card but another user has the same problem but with an IDE DVD burner ( mixed with an IDE hardidsk ) : https://bugzilla.kernel.org/show_bug.cgi?id=87581#c18 this user has tested your patch and it solves the bug Le 24/11/2014 10:18, Christoph Hellwig a écrit : > On Thu, Nov 20, 20

Re: BUG in scsi_lib.c due to a bad commit

00.0: AHCI 0001.0100 32 slots 2 ports 3 Gbps 0x3 impl SATA mode [0.883508] ahci :03:00.0: flags: 64bit ncq pm led clo pmp pio slum part [0.884329] scsi host6: ahci [0.884502] scsi host7: ahci Le 20/11/2014 18:53, Christoph Hellwig a écrit : > On Thu, Nov 20, 2014 at 06:44:32PM +0100

Re: BUG in scsi_lib.c due to a bad commit

E emulation mode ) and a Sata DVD burner, in this case you will have 20~30% of chance to trigger the bug ( random hangs will occur approximately every 5~10 boots ) Le 20/11/2014 07:09, Christoph Hellwig a écrit : > I > > Hi Barto, > > sorry for the late reply, and thanks for dril

Re: BUG in scsi_lib.c due to a bad commit

ices, it breaks compatibility with some PC configurations ? ) Le 14/11/2014 08:32, Christoph Hellwig a écrit : > On Thu, Nov 13, 2014 at 11:55:38PM +0100, Barto wrote: >> it's interesting, with this commit >> 74665016086615bbaa3fa6f83af410a0a4e029ee I have the bug : >&g

Re: BUG in scsi_lib.c due to a bad commit

2014 08:32, Christoph Hellwig a écrit : > On Thu, Nov 13, 2014 at 11:55:38PM +0100, Barto wrote: >> it's interesting, with this commit >> 74665016086615bbaa3fa6f83af410a0a4e029ee I have the bug : >> >> scsi: convert host_busy to atomic_t :

Re: BUG in scsi_lib.c due to a bad commit

Thu, Nov 13, 2014 at 11:55:38PM +0100, Barto wrote: >> it's interesting, with this commit >> 74665016086615bbaa3fa6f83af410a0a4e029ee I have the bug : >> >> scsi: convert host_busy to atomic_t : > > At this point we'll need a bisction

Re: BUG in scsi_lib.c due to a bad commit

sting, with this commit 74665016086615bbaa3fa6f83af410a0a4e029ee I have the bug : scsi: convert host_busy to atomic_t : http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=74665016086615bbaa3fa6f83af410a0a4e029ee Le 13/11/2014 18:54, Christoph Hellwig a écrit : > On Thu, Nov 13, 2014 at 06:14:14PM +0100, Barto

Re: BUG in scsi_lib.c due to a bad commit

Hello Christoph, I tested this commit : 7ae65c0f9646c29432b69580b80e08632e6cd813 scsi: convert target_busy to an atomic_t http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7ae65c0f9646c29432b69580b80e08632e6cd813 there is no bug, boot process is ok whit this commit, whe

Re: BUG in scsi_lib.c due to a bad commit

I am not sure to understand your request, it's quite confusing, you ask me to revert this commit and see if the bug is gone ? : 74665016086615bbaa3fa6f83af410a0a4e029ee scsi: convert host_busy to atomic_t http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=74665016086615bba

Re: BUG in scsi_lib.c due to a bad commit

i source code, check if some parts in the source code acts really like it should be ? Le 13/11/2014 06:33, Elliott, Robert (Server Storage) a écrit : > > >> -Original Message- >> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- >> ow...@vger.kernel.o

Re: BUG in scsi_lib.c due to a bad commit

cc Guenter, linux-scsi] >> >> On Tue, Nov 11, 2014 at 4:33 PM, Barto >> wrote: >>> Hello everyone, >>> >>> I notice a bug since kernel 3.17 ( and also with 3.18 branch ), a random >>> hang at boot on some PC configurations, I did a "git bis

BUG in scsi_lib.c due to a bad commit

Hello everyone, I notice a bug since kernel 3.17 ( and also with 3.18 branch ), a random hang at boot on some PC configurations, I did a "git bisect" and I found that the culprit is : [045065d8a300a37218c548e9aa7becd581c6a0e8] [SCSI] fix qemu boot hang problem http://git.kernel.org/cgit/linux/k

Re: new test

Hello Liu Chuansheng, I have good news, your patch based on /drivers/pci/quirks.c works very well, I have no problems after a standby mode, my JMB363/368 SATA/IDE JMicron Pcie works without problems Le 06/11/2014 15:33, Liu, Chuansheng a écrit : > Thanks Barto. > > Could you try be

Re: [PATCH] PCI: Do not enable async suspend for JMicron chips

> The idea of a quirk is to work around a defect in a device. What is > the defect in this case? It seems there are two devices involved, > e.g. (from https://bugzilla.kernel.org/show_bug.cgi?id=81551): > > 02:00.0 JMicron Technology Corp. JMB363 SATA/IDE Controller > 02:00.1 JMicron Techno

Re: [PATCH] PCI: Do not enable async suspend for JMicron chips

_PCI_FIXUP_FINAL(PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, > pci_async_suspend_fixup); > + > static const struct pci_device_id jmicron_pci_tbl[] = { > { PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, > PCI_CLASS_STORAGE_IDE << 8, 0x00, 0 }, > > Barto, > Could you have

Re: [PATCH] PCI: Do not enable async suspend for JMicron chips

Hello Bjorn, in my bugreport I have already tried to add the JMicron 368 in the "if statement" and it didn't work, check my message here : https://bugzilla.kernel.org/show_bug.cgi?id=84861#c11 if Chuansheng has choosen a more generic way ( applying the patch to all JMicron devices ) it's becaus

Re: [PATCH] PCI: Do not enable async suspend for JMicron chips

t;dev); dev->wakeup_prepared = false; Le 05/11/2014 20:03, Bjorn Helgaas a écrit : > On Wed, Nov 5, 2014 at 11:46 AM, Barto wrote: >> this patch solves these 2 bug reports : >> >> https://bugzilla.kernel.org/show_bug.cgi?id= >> >> https://bugzil

Re: [PATCH] PCI: Do not enable async suspend for JMicron chips

this patch solves these 2 bug reports : https://bugzilla.kernel.org/show_bug.cgi?id=84861 https://bugzilla.kernel.org/show_bug.cgi?id=81551 in simple words : JMicron IDE/Sata controlers family ( JMBxxx ) are not fully compatible with async_suspend feature, when a user tries to put his PC on stan

Re: [PATCH] PCI: Do not enable async suspend for JMicron chips

I tried the patch, it solves the problem, but I had to change the patch in order to be compatible with 3.18rc3 source code : patching file drivers/pci/pci.c Hunk #1 FAILED at 2046. 1 out of 1 hunk FAILED -- saving rejects to file drivers/pci/pci.c.rej here is the correct patch for kernel 3.18rc3

Re: FW: [PATCH V2] ata: Disabling the async PM for JMicron chips

t e6b7e41cdd8c ("ata: Disabling the async PM for JMicron chip > 363/361"), > Barto found the similar issue for JMicron chip 368, that 363/368 has no > parent-children relationship, but they have the power dependency. > > So here we can exclude the JMicron chips out of pm_