arcmsr: abort device command message weirdness (LUN mismatch)

2017-06-11 Thread Jérôme Carretero
Hi Ching, Context: when a drive finally failed in my JBOD array, I discovered that the whole ARC1880X controller would timeout, disabling access to any drive, which is kind of sad. I've performed a firmware upgrade and added back the failing drive to see what happens with a newer device firmware

arcmsr: abort device command message weirdness (LUN mismatch)

2017-06-11 Thread Jérôme Carretero
Hi Ching, Context: when a drive finally failed in my JBOD array, I discovered that the whole ARC1880X controller would timeout, disabling access to any drive, which is kind of sad. I've performed a firmware upgrade and added back the failing drive to see what happens with a newer device firmware

i915 (ivy bridge) + 4.10.3 + gimp = BUG in list_move_tail()

2017-03-19 Thread Jérôme Carretero
Hi, After a kernel update from v4.9.10 to v4.10.3, any time I bring out the gimp, the i915 driver NULL-pointer dereferences something in list_move_tail(), somewhere in i915_gem_evict_for_vma(). I'm providing the kernel log, if more is needed (say you aren't aware of this regression) I'm

i915 (ivy bridge) + 4.10.3 + gimp = BUG in list_move_tail()

2017-03-19 Thread Jérôme Carretero
Hi, After a kernel update from v4.9.10 to v4.10.3, any time I bring out the gimp, the i915 driver NULL-pointer dereferences something in list_move_tail(), somewhere in i915_gem_evict_for_vma(). I'm providing the kernel log, if more is needed (say you aren't aware of this regression) I'm

[PATCH] PCI: quirk dma_alias_devfn for HighPoint RocketRaid 642L (Marvell 9235)

2014-06-03 Thread Jérôme Carretero
, and even with IOMMU. Nice! Signed-off-by: Jérôme Carretero --- drivers/pci/quirks.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index f6a42bc..43c0ea0 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -3380,6 +3380,8

[PATCH] ahci: Add Device ID for HighPoint RocketRaid 642L

2014-06-03 Thread Jérôme Carretero
be supported but not tested here. Signed-off-by: Jérôme Carretero --- drivers/ata/ahci.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c index 6070781..ff5543f 100644 --- a/drivers/ata/ahci.c +++ b/drivers/ata/ahci.c @@ -449,6 +449,8 @@ static const struct

Re: [PATCH] ahci: Add Device ID for HighPoint RocketRaid 642L

2014-06-03 Thread Jérôme Carretero
On Tue, 3 Jun 2014 14:41:40 -0400 Tejun Heo wrote: > Ugh... build failure from missing ')'. Please at least try to compile > the changes before submitting patches. Argh. Sorry, I hadn't used git send-mail and missed the copy/paste... Shall I send a corrected version or you fixed it? --

Re: [PATCH] ahci: Add Device ID for HighPoint RocketRaid 642L

2014-06-03 Thread Jérôme Carretero
On Tue, 3 Jun 2014 14:41:40 -0400 Tejun Heo t...@kernel.org wrote: Ugh... build failure from missing ')'. Please at least try to compile the changes before submitting patches. Argh. Sorry, I hadn't used git send-mail and missed the copy/paste... Shall I send a corrected version or you fixed

[PATCH] ahci: Add Device ID for HighPoint RocketRaid 642L

2014-06-03 Thread Jérôme Carretero
be supported but not tested here. Signed-off-by: Jérôme Carretero cj...@zougloub.eu --- drivers/ata/ahci.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c index 6070781..ff5543f 100644 --- a/drivers/ata/ahci.c +++ b/drivers/ata/ahci.c @@ -449,6 +449,8

[PATCH] PCI: quirk dma_alias_devfn for HighPoint RocketRaid 642L (Marvell 9235)

2014-06-03 Thread Jérôme Carretero
, and even with IOMMU. Nice! Signed-off-by: Jérôme Carretero cj...@zougloub.eu --- drivers/pci/quirks.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index f6a42bc..43c0ea0 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -3380,6 +3380,8

Re: Bad DMA from Marvell 9230

2014-05-30 Thread Jérôme Carretero
On Fri, 30 May 2014 09:13:43 -0500 Roger Heflin wrote: > I had a 9230... > [...] > Supplier support "claimed" it to be a Linux AHCI bug as the "claim" > that their board correctly supports AHCI, even though all other AHCI > boards work right in this exact same use case in the exact same >

Re: Bad DMA from Marvell 9230

2014-05-30 Thread Jérôme Carretero
On Fri, 30 May 2014 20:37:58 +1000 Benjamin Herrenschmidt wrote: > We've switched to a 9235 instead which seems to work fine. Weird (I hadn't seen that you reported the 9235 working...), I have IOMMU problems with a 9235... What system are you running it on (when you say "power box", is it a

Re: Bad DMA from Marvell 9230

2014-05-30 Thread Jérôme Carretero
On Thu, 27 Mar 2014 17:57:37 +1100 Benjamin Herrenschmidt wrote: > I've been trying a 9230 on a power box here (a 9235 on the same > machine works fine) and it blows up with an IOMMU violation early > during init. Hi, That's https://bugzilla.kernel.org/show_bug.cgi?id=42679 if you haven't

[PATCH] ahci: Add Device ID for HighPoint RocketRaid 642L

2014-05-30 Thread Jérôme Carretero
be supported but not tested here. Signed-off-by: Jérôme Carretero --- drivers/ata/ahci.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c index 6070781..ff5543f 100644 --- a/drivers/ata/ahci.c +++ b/drivers/ata/ahci.c @@ -449,6 +449,8 @@ static const struct

[PATCH] ahci: Add Device ID for HighPoint RocketRaid 642L

2014-05-30 Thread Jérôme Carretero
be supported but not tested here. Signed-off-by: Jérôme Carretero cj...@zougloub.eu --- drivers/ata/ahci.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c index 6070781..ff5543f 100644 --- a/drivers/ata/ahci.c +++ b/drivers/ata/ahci.c @@ -449,6 +449,8

Re: Bad DMA from Marvell 9230

2014-05-30 Thread Jérôme Carretero
On Thu, 27 Mar 2014 17:57:37 +1100 Benjamin Herrenschmidt b...@kernel.crashing.org wrote: I've been trying a 9230 on a power box here (a 9235 on the same machine works fine) and it blows up with an IOMMU violation early during init. Hi, That's

Re: Bad DMA from Marvell 9230

2014-05-30 Thread Jérôme Carretero
On Fri, 30 May 2014 20:37:58 +1000 Benjamin Herrenschmidt b...@kernel.crashing.org wrote: We've switched to a 9235 instead which seems to work fine. Weird (I hadn't seen that you reported the 9235 working...), I have IOMMU problems with a 9235... What system are you running it on (when you say

Re: Bad DMA from Marvell 9230

2014-05-30 Thread Jérôme Carretero
On Fri, 30 May 2014 09:13:43 -0500 Roger Heflin rogerhef...@gmail.com wrote: I had a 9230... [...] Supplier support claimed it to be a Linux AHCI bug as the claim that their board correctly supports AHCI, even though all other AHCI boards work right in this exact same use case in the exact

Re: [PATCH] usbcore: fix BABBLE failed enumeration of legacy USB2 devices on USB3 bus

2014-01-17 Thread Jérôme Carretero
Hi, I encountered the same problem with another device. If possible, it would be nice to pick Marius's patch for stable kernels (tested here on v3.12.6). There are chances that MacOSX is affected by a similar issue, so if anybody has friends there... Thanks, -- Jérôme On Wed, 8 Jan 2014

Re: [PATCH] usbcore: fix BABBLE failed enumeration of legacy USB2 devices on USB3 bus

2014-01-17 Thread Jérôme Carretero
Hi, I encountered the same problem with another device. If possible, it would be nice to pick Marius's patch for stable kernels (tested here on v3.12.6). There are chances that MacOSX is affected by a similar issue, so if anybody has friends there... Thanks, -- Jérôme On Wed, 8 Jan 2014

xhci_hcd: Signal/Timeout while waiting for evaluate context command then Assuming host is dying, halting host

2013-06-25 Thread Jérôme Carretero
Hi, I am seeing that with an acquisition board: [27044.406737] usb 4-4.4: usb_probe_device [27044.406739] usb 4-4.4: configuration #1 chosen from 1 choice [27044.406803] usb 4-4.4: Successful Endpoint Configure command [27044.418946] usb 4-4.4: Successful evaluate context command [27044.421725]

xhci_hcd: Signal/Timeout while waiting for evaluate context command then Assuming host is dying, halting host

2013-06-25 Thread Jérôme Carretero
Hi, I am seeing that with an acquisition board: [27044.406737] usb 4-4.4: usb_probe_device [27044.406739] usb 4-4.4: configuration #1 chosen from 1 choice [27044.406803] usb 4-4.4: Successful Endpoint Configure command [27044.418946] usb 4-4.4: Successful evaluate context command [27044.421725]

Re: [Regression] "x86-64/efi: Use EFI to deal with platform wall clock" prevents my machine from booting

2012-08-09 Thread Jérôme Carretero
ERTOOTH 990FX [CASEID=WTM201208072118475482] Apply date : 8/7/2012 1:18:47 PM(UTC Time) [Contact Information] *Name : Jérôme Carretero *Email Address : cj...@zougloub.eu [Product Information] *Product Type : Motherboard *Product Model : SABERTOOTH 990FX *Product S/N : MB-1234567890

Re: [Regression] x86-64/efi: Use EFI to deal with platform wall clock prevents my machine from booting

2012-08-09 Thread Jérôme Carretero
[CASEID=WTM201208072118475482] Apply date : 8/7/2012 1:18:47 PM(UTC Time) [Contact Information] *Name : Jérôme Carretero *Email Address : cj...@zougloub.eu [Product Information] *Product Type : Motherboard *Product Model : SABERTOOTH 990FX *Product S/N : MB-1234567890 [Motherboard

Re: [Regression] "x86-64/efi: Use EFI to deal with platform wall clock" prevents my machine from booting

2012-08-06 Thread Jérôme Carretero
On Mon, 6 Aug 2012 22:32:08 -0400 Jérôme Carretero wrote: > For troubleshooting purposes I edited over your patch. > So far: > [...] > Maybe I can get more... With the following: diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c index 2dc29f5..46729f3 100644 --

Re: [Regression] "x86-64/efi: Use EFI to deal with platform wall clock" prevents my machine from booting

2012-08-06 Thread Jérôme Carretero
On Mon, 6 Aug 2012 09:16:27 -0400 Jérôme Carretero wrote: > - I can bisect the patch further down (might be a bit silly because > I don't quite understand it), For troubleshooting purposes I edited over your patch. So far: - (in arch/x86/platform/efi/efi.c) when making efi_ge

Re: [Regression] "x86-64/efi: Use EFI to deal with platform wall clock" prevents my machine from booting

2012-08-06 Thread Jérôme Carretero
On Mon, 06 Aug 2012 14:25:33 +0100 "Jan Beulich" wrote: > >>> On 06.08.12 at 15:16, JérômeCarretero wrote: > > If it helps: > > > > - I can bisect the patch further down (might be a bit silly because > > I don't quite understand it), > > - you can suggest some modifications and at least I

Re: [Regression] "x86-64/efi: Use EFI to deal with platform wall clock" prevents my machine from booting

2012-08-06 Thread Jérôme Carretero
On Mon, 06 Aug 2012 14:08:03 +0100 "Jan Beulich" wrote: > with the change at hand I merely tried to be proactive). Jan, If it helps: - I can bisect the patch further down (might be a bit silly because I don't quite understand it), - you can suggest some modifications and at least I can test

Re: [Regression] x86-64/efi: Use EFI to deal with platform wall clock prevents my machine from booting

2012-08-06 Thread Jérôme Carretero
On Mon, 06 Aug 2012 14:08:03 +0100 Jan Beulich jbeul...@suse.com wrote: with the change at hand I merely tried to be proactive). Jan, If it helps: - I can bisect the patch further down (might be a bit silly because I don't quite understand it), - you can suggest some modifications and at

Re: [Regression] x86-64/efi: Use EFI to deal with platform wall clock prevents my machine from booting

2012-08-06 Thread Jérôme Carretero
On Mon, 06 Aug 2012 14:25:33 +0100 Jan Beulich jbeul...@suse.com wrote: On 06.08.12 at 15:16, JérômeCarretero cj...@zougloub.eu wrote: If it helps: - I can bisect the patch further down (might be a bit silly because I don't quite understand it), - you can suggest some modifications

Re: [Regression] x86-64/efi: Use EFI to deal with platform wall clock prevents my machine from booting

2012-08-06 Thread Jérôme Carretero
On Mon, 6 Aug 2012 09:16:27 -0400 Jérôme Carretero cj...@zougloub.eu wrote: - I can bisect the patch further down (might be a bit silly because I don't quite understand it), For troubleshooting purposes I edited over your patch. So far: - (in arch/x86/platform/efi/efi.c) when making

Re: [Regression] x86-64/efi: Use EFI to deal with platform wall clock prevents my machine from booting

2012-08-06 Thread Jérôme Carretero
On Mon, 6 Aug 2012 22:32:08 -0400 Jérôme Carretero cj...@zougloub.eu wrote: For troubleshooting purposes I edited over your patch. So far: [...] Maybe I can get more... With the following: diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c index 2dc29f5..46729f3 100644

[Regression] "x86-64/efi: Use EFI to deal with platform wall clock" prevents my machine from booting

2012-08-05 Thread Jérôme Carretero
Hi, My PC (AMD Bulldozer + Asus SABERTOOTH 990FX) booted fine from UEFI and it broke between v3.5 and v3.6-rc1. Other machines with old BIOSes booted fine so I looked into EFI-related patches trying to revert them, because I didn't know what else to do. Bingo, bacef661: x86-64/efi: Use EFI to

[Regression] x86-64/efi: Use EFI to deal with platform wall clock prevents my machine from booting

2012-08-05 Thread Jérôme Carretero
Hi, My PC (AMD Bulldozer + Asus SABERTOOTH 990FX) booted fine from UEFI and it broke between v3.5 and v3.6-rc1. Other machines with old BIOSes booted fine so I looked into EFI-related patches trying to revert them, because I didn't know what else to do. Bingo, bacef661: x86-64/efi: Use EFI to