Re: [patch 2/7] drm/vmgfx: Replace kmap_atomic()

n pgprot. > > Remove the NULL pointer check for the map. These functions return a valid > address for valid pages and the return was bogus anyway as it would have > left preemption and pagefaults disabled. > > Signed-off-by: Thomas Gleixner > Cc: VMware Graphics > Cc: Rola

Re: [RESEND 00/53] Rid GPU from W=1 warnings

The vmwgfx ones look all good to me, so for 23-53: Reviewed-by: Roland Scheidegger That said, they were already signed off by Zack, so not sure what happened here. Roland On 03.03.21 14:42, Lee Jones wrote: > This is a resend. All of these patches have been sent before. > > The vm

Re: [PATCH 5.8 050/124] drm/vmwgfx: Fix error handling in get_node

it ended up as a candidate for 5.8. Roland Am 12.10.20 um 15:30 schrieb Greg Kroah-Hartman: > From: Zack Rusin > > [ Upstream commit f54c4442893b8dfbd3aff8e903c54dfff1aef990 ] > > ttm_mem_type_manager_func.get_node was changed to return -ENOSPC > instead of setting the no

Re: [PATCH AUTOSEL 5.8 10/12] drm/vmwgfx: Fix error handling in get_node

interface v3), and at least I don't see that one being backported to 5.8. Roland Am 05.10.20 um 16:44 schrieb Sasha Levin: > From: Zack Rusin > > [ Upstream commit f54c4442893b8dfbd3aff8e903c54dfff1aef990 ] > > ttm_mem_type_manager_func.get_node was changed to return -ENOSPC >

Re: [vmwgfx] Xwayland crash on latest linus git

I'm now able to reproduce this, looking into it. (The crash looks actually similar to what was also happening with the next commit, drm/ttm: make TT creation purely optional v3, but that got reverted already.) Roland Am 19.08.20 um 09:47 schrieb 허종만: > > Hi, > > > I'm running

Re: [PATCH] drm/vmwgfx: fix spelling mistake "Cant" -> "Can't"

Thanks, I've put the fix in the vmwgfx-next branch. Roland Am 10.08.20 um 12:04 schrieb Colin King: > From: Colin Ian King > > There is a spelling mistake in a DRM_ERROR message. Fix it. > > Signed-off-by: Colin Ian King > --- > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2

Re: [PATCH][next] drm/vmwgfx: Use struct_size() helper

I've commited this to our next branch, thanks! (I'm actually kind of impressed this can be found automatically...) Roland Am 17.06.20 um 23:51 schrieb Gustavo A. R. Silva: > Make use of the struct_size() helper instead of an open-coded version > in order to avoid any potential type mi

Re: [Linux-graphics-maintainer] [PATCH] drm/vmwgfx: Return true in function vmw_fence_obj_signaled()

I've pulled that into our tree, thanks! Roland Am 07.05.20 um 13:07 schrieb Jason Yan: > Fix the following coccicheck warning: > > drivers/gpu/drm/vmwgfx/vmwgfx_fence.c:518:9-10: WARNING: return of 0/1 > in function 'vmw_fence_obj_signaled' with return type bool > > Signed

Re: [Linux-graphics-maintainer] [PATCH v3 15/25] drm: vmwgfx: fix common struct sg_table related issues

I'm not exactly an expert on this, but looks alright to me. Acked-by: Roland Scheidegger Am 05.05.20 um 10:46 schrieb Marek Szyprowski: > The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the > numer of the created entries in the DMA address space. However the > subsequ

Re: [PATCH 1/2] block: drbd: Fix a possible null-pointer dereference in receive_protocol()

by us. > > Signed-off-by: Jia-Ju Bai Reviewed-by: Roland Kammerer

Re: [Drbd-dev] [PATCH] block: Mark expected switch fall-throughs

4 files changed, 5 insertions(+), 4 deletions(-) > Hi Gustavo, as also discussed with Lars in person, obviously OK for the DRBD part. Acked-by: Roland Kammerer Best, rck

Re: [PATCH] clocksource: Add heuristics to avoid switching away from TSC due to timer delay

than HPET but there may be other architectures that could hit the same problem, just with the clocksource being checked wrapping around instead of the watchdog clocksource. Right? Thanks! Roland

Re: [PATCH] clocksource: Add heuristics to avoid switching away from TSC due to timer delay

than HPET but there may be other architectures that could hit the same problem, just with the clocksource being checked wrapping around instead of the watchdog clocksource. Right? Thanks! Roland

[tip:x86/timers] x86/hpet: Remove unused FSEC_PER_NSEC define

Commit-ID: d999c0ec2498e54b9328db6b2c1037710025add1 Gitweb: https://git.kernel.org/tip/d999c0ec2498e54b9328db6b2c1037710025add1 Author: Roland Dreier AuthorDate: Fri, 30 Nov 2018 13:14:50 -0800 Committer: Borislav Petkov CommitDate: Tue, 4 Dec 2018 12:17:21 +0100 x86/hpet: Remove

[tip:x86/timers] x86/hpet: Remove unused FSEC_PER_NSEC define

Commit-ID: d999c0ec2498e54b9328db6b2c1037710025add1 Gitweb: https://git.kernel.org/tip/d999c0ec2498e54b9328db6b2c1037710025add1 Author: Roland Dreier AuthorDate: Fri, 30 Nov 2018 13:14:50 -0800 Committer: Borislav Petkov CommitDate: Tue, 4 Dec 2018 12:17:21 +0100 x86/hpet: Remove

[PATCH] x86/hpet: Remove unused FSEC_PER_NSEC define

The FSEC_PER_NSEC macro has had zero users since commit ab0e08f15d23 ("x86: hpet: Cleanup the clockevents init and register code"). Signed-off-by: Roland Dreier --- arch/x86/kernel/hpet.c | 4 1 file changed, 4 deletions(-) diff --git a/arch/x86/kernel/hpet.c b/arch/x86/ker

[PATCH] x86/hpet: Remove unused FSEC_PER_NSEC define

The FSEC_PER_NSEC macro has had zero users since commit ab0e08f15d23 ("x86: hpet: Cleanup the clockevents init and register code"). Signed-off-by: Roland Dreier --- arch/x86/kernel/hpet.c | 4 1 file changed, 4 deletions(-) diff --git a/arch/x86/kernel/hpet.c b/arch/x86/ker

[PATCH] clocksource: Add heuristics to avoid switching away from TSC due to timer delay

detection of true instability very likely within a few clocksource watchdog iterations. Signed-off-by: Roland Dreier --- kernel/time/clocksource.c | 35 +++ 1 file changed, 35 insertions(+) diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c index

[PATCH] clocksource: Add heuristics to avoid switching away from TSC due to timer delay

detection of true instability very likely within a few clocksource watchdog iterations. Signed-off-by: Roland Dreier --- kernel/time/clocksource.c | 35 +++ 1 file changed, 35 insertions(+) diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c index

[PATCH] x86/hpet: Remove unused FSEC_PER_NSEC define

The FSEC_PER_NSEC macro has had zero users since commit ab0e08f15d23 ("x86: hpet: Cleanup the clockevents init and register code"). Signed-off-by: Roland Dreier --- arch/x86/kernel/hpet.c | 4 1 file changed, 4 deletions(-) diff --git a/arch/x86/kernel/hpet.c b/arch/x86/ker

[PATCH] x86/hpet: Remove unused FSEC_PER_NSEC define

The FSEC_PER_NSEC macro has had zero users since commit ab0e08f15d23 ("x86: hpet: Cleanup the clockevents init and register code"). Signed-off-by: Roland Dreier --- arch/x86/kernel/hpet.c | 4 1 file changed, 4 deletions(-) diff --git a/arch/x86/kernel/hpet.c b/arch/x86/ker

editing for your photos

can provide you editing test on your photos. Please reply if you are interested. Thanks, Roland

editing for your photos

can provide you editing test on your photos. Please reply if you are interested. Thanks, Roland

your photos

can provide you editing test on your photos. Please reply if you are interested. Thanks, Roland

your photos

can provide you editing test on your photos. Please reply if you are interested. Thanks, Roland

your photos

can provide you editing test on your photos. Please reply if you are interested. Thanks, Roland

your photos

can provide you editing test on your photos. Please reply if you are interested. Thanks, Roland

for your photos

can provide you editing test on your photos. Please reply if you are interested. Thanks, Roland

for your photos

can provide you editing test on your photos. Please reply if you are interested. Thanks, Roland

for your photos

can provide you editing test on your photos. Please reply if you are interested. Thanks, Roland

for your photos

can provide you editing test on your photos. Please reply if you are interested. Thanks, Roland

Re: [PATCH 0/3] Provide more fine grained control over multipathing

> The sensible thing to do in nvme is to use different paths for > different queues. That is e.g. in the RDMA case use the HCA closer > to a given CPU by default. We might allow to override this for > cases where the is a good reason, but what I really don't want is > configurability for

Re: [PATCH 0/3] Provide more fine grained control over multipathing

> The sensible thing to do in nvme is to use different paths for > different queues. That is e.g. in the RDMA case use the HCA closer > to a given CPU by default. We might allow to override this for > cases where the is a good reason, but what I really don't want is > configurability for

Re: [PATCH 0/3] Provide more fine grained control over multipathing

> Moreover, I also wanted to point out that fabrics array vendors are > building products that rely on standard nvme multipathing (and probably > multipathing over dispersed namespaces as well), and keeping a knob that > will keep nvme users with dm-multipath will probably not help them > educate

Re: [PATCH 0/3] Provide more fine grained control over multipathing

> Moreover, I also wanted to point out that fabrics array vendors are > building products that rely on standard nvme multipathing (and probably > multipathing over dispersed namespaces as well), and keeping a knob that > will keep nvme users with dm-multipath will probably not help them > educate

Re: KASAN: use-after-free Read in __list_add_valid (5)

> Still reproducible on Linus' tree (commit 66e1c94db3cd4e) and on linux-next > (next-20180511). Here's a simplified reproducer: Thanks! That's a fantastic test case. The issue is a race where rdma_listen() sees invalid state in the middle of an rdma_bind_addr() call that will ultimately fail.

Re: KASAN: use-after-free Read in __list_add_valid (5)

> Still reproducible on Linus' tree (commit 66e1c94db3cd4e) and on linux-next > (next-20180511). Here's a simplified reproducer: Thanks! That's a fantastic test case. The issue is a race where rdma_listen() sees invalid state in the middle of an rdma_bind_addr() call that will ultimately fail.

Re: [Drbd-dev] [PATCH] drdb: fix print_st_err()'s prototype

On Tue, Apr 24, 2018 at 03:14:10PM +0200, Luc Van Oostenryck wrote: > print_st_err() is defined with its 4th argument taking an > 'enum drbd_state_rv' but its prototype use an int for it. > > Fix this by using 'enum drbd_state_rv' in the prototype too. > > Signed-off-by: Luc Van Oostenryck

Re: [Drbd-dev] [PATCH] drdb: fix print_st_err()'s prototype

On Tue, Apr 24, 2018 at 03:14:10PM +0200, Luc Van Oostenryck wrote: > print_st_err() is defined with its 4th argument taking an > 'enum drbd_state_rv' but its prototype use an int for it. > > Fix this by using 'enum drbd_state_rv' in the prototype too. > > Signed-off-by: Luc Van Oostenryck >

Re: [Drbd-dev] [PATCH] block/drbd: Fix a sleep-in-atomic bug in drbd_bcast_event

On Wed, Oct 04, 2017 at 09:33:18AM +0800, Jia-Ju Bai wrote: > The driver may sleep under a RCU lock, and the function call path is: > drbd_sync_handshake (acquire the RCU lock) > drbd_asb_recover_1p > drbd_khelper > drbd_bcast_event > genlmsg_new(GFP_NOIO) --> may sleep > > To

Re: [Drbd-dev] [PATCH] block/drbd: Fix a sleep-in-atomic bug in drbd_bcast_event

On Wed, Oct 04, 2017 at 09:33:18AM +0800, Jia-Ju Bai wrote: > The driver may sleep under a RCU lock, and the function call path is: > drbd_sync_handshake (acquire the RCU lock) > drbd_asb_recover_1p > drbd_khelper > drbd_bcast_event > genlmsg_new(GFP_NOIO) --> may sleep > > To

Re: [Patch v2 00/19] CIFS: Implement SMBDirect

> Starting with SMB2 dialect 3.0, Microsoft introduced SMBDirect transport > protocol for transferring upper layer (SMB2) payload over RDMA via > Infiniband, RoCE or iWARP. The prococol is published in [MS-SMBD] > (https://msdn.microsoft.com/en-us/library/hh536346.aspx). This is great to see.

Re: [Patch v2 00/19] CIFS: Implement SMBDirect

> Starting with SMB2 dialect 3.0, Microsoft introduced SMBDirect transport > protocol for transferring upper layer (SMB2) payload over RDMA via > Infiniband, RoCE or iWARP. The prococol is published in [MS-SMBD] > (https://msdn.microsoft.com/en-us/library/hh536346.aspx). This is great to see.

Re: [Drbd-dev] [PATCH] drbd: rename "usermode_helper" to "drbd_usermode_helper"

On Thu, Jul 06, 2017 at 08:02:41PM +0200, Greg KH wrote: > On Thu, Jul 06, 2017 at 07:56:07PM +0200, Roland Kammerer wrote: > > On Mon, Jun 05, 2017 at 11:26:23AM +0200, Greg KH wrote: > > > From: Greg Kroah-Hartman <gre...@linuxfoundation.org> > > > > &g

Re: [Drbd-dev] [PATCH] drbd: rename "usermode_helper" to "drbd_usermode_helper"

On Thu, Jul 06, 2017 at 08:02:41PM +0200, Greg KH wrote: > On Thu, Jul 06, 2017 at 07:56:07PM +0200, Roland Kammerer wrote: > > On Mon, Jun 05, 2017 at 11:26:23AM +0200, Greg KH wrote: > > > From: Greg Kroah-Hartman > > > > > > Nothing like having a very gene

Re: [Drbd-dev] [PATCH] drbd: rename "usermode_helper" to "drbd_usermode_helper"

t happen magically in mainline, I queued it up in our out-of-tree repo. > > Note, there are many other "generic" named global variables in the drbd > subsystem, someone should fix those up one day before they hit a linking > error. Did that as well. Both should hit some me

Re: [Drbd-dev] [PATCH] drbd: rename "usermode_helper" to "drbd_usermode_helper"

queued it up in our out-of-tree repo. > > Note, there are many other "generic" named global variables in the drbd > subsystem, someone should fix those up one day before they hit a linking > error. Did that as well. Both should hit some merge-window soon. Thanks, rc

Re: [PATCH 3/9] drbd: Drop unnecessary static

bd_nl.c > @@ -2294,7 +2294,7 @@ static bool conn_ov_running(struct drbd_connection > *connection) > static enum drbd_ret_code > check_net_options(struct drbd_connection *connection, struct net_conf > *new_net_conf) > { > - static enum drbd_ret_code rv; > + enum

Re: [PATCH 3/9] drbd: Drop unnecessary static

294,7 @@ static bool conn_ov_running(struct drbd_connection > *connection) > static enum drbd_ret_code > check_net_options(struct drbd_connection *connection, struct net_conf > *new_net_conf) > { > - static enum drbd_ret_code rv; > + enum drbd_ret_code rv; > struct drbd_peer_device *peer_device; > int i; Yes, that already got dropped for drbd9 and is obviously correct for in-tree drbd8. Signed-off-by: Roland Kammerer Regards, rck

Re: [patch 0/2] tsc/adjust: Cure suspend/resume issues and prevent TSC deadline timer irq storm

rectly because the TSC would change). (And I'd guess better avoid an armed deadline timer while changing TSC_ADJ...) In any case, I've tested the two patches on top of x86-timers and they work just fine - all TSC_ADJ values get set to zero both on boot and resume, no lockups, and tsc

Re: [patch 0/2] tsc/adjust: Cure suspend/resume issues and prevent TSC deadline timer irq storm

rectly because the TSC would change). (And I'd guess better avoid an armed deadline timer while changing TSC_ADJ...) In any case, I've tested the two patches on top of x86-timers and they work just fine - all TSC_ADJ values get set to zero both on boot and resume, no lockups, and tsc clocksource

Re: [patch 0/2] tsc/adjust: Cure suspend/resume issues and prevent TSC deadline timer irq storm

Am 13.12.2016 um 17:46 schrieb Thomas Gleixner: > On Tue, 13 Dec 2016, Roland Scheidegger wrote: > >> Am 13.12.2016 um 14:14 schrieb Thomas Gleixner: >>> Roland reported interesting TSC ADJUST register wreckage on his DELL >>> machine, which seems to populate

Re: [patch 0/2] tsc/adjust: Cure suspend/resume issues and prevent TSC deadline timer irq storm

Am 13.12.2016 um 17:46 schrieb Thomas Gleixner: > On Tue, 13 Dec 2016, Roland Scheidegger wrote: > >> Am 13.12.2016 um 14:14 schrieb Thomas Gleixner: >>> Roland reported interesting TSC ADJUST register wreckage on his DELL >>> machine, which seems to populate

Re: [patch 0/2] tsc/adjust: Cure suspend/resume issues and prevent TSC deadline timer irq storm

Am 13.12.2016 um 14:14 schrieb Thomas Gleixner: > Roland reported interesting TSC ADJUST register wreckage on his DELL > machine, which seems to populate that MSR with a random number generator. FWIW, I thought about the actual values some more and I don't actually think they are all that

Re: [patch 0/2] tsc/adjust: Cure suspend/resume issues and prevent TSC deadline timer irq storm

Am 13.12.2016 um 14:14 schrieb Thomas Gleixner: > Roland reported interesting TSC ADJUST register wreckage on his DELL > machine, which seems to populate that MSR with a random number generator. FWIW, I thought about the actual values some more and I don't actually think they are all that

Re: [PATCH] x86/tsc: RFC: re-synchronize TSCs to boot cpu TSC

Am 10.12.2016 um 02:55 schrieb Roland Scheidegger: > Am 09.12.2016 um 23:59 schrieb Thomas Gleixner: >> On Fri, 9 Dec 2016, Roland Scheidegger wrote: >> >> Cc'ed someone from Dell. >> >>> Am 09.12.2016 um 18:33 schrieb Thomas Gleixner: >>>> Can yo

Re: [PATCH] x86/tsc: RFC: re-synchronize TSCs to boot cpu TSC

Am 10.12.2016 um 02:55 schrieb Roland Scheidegger: > Am 09.12.2016 um 23:59 schrieb Thomas Gleixner: >> On Fri, 9 Dec 2016, Roland Scheidegger wrote: >> >> Cc'ed someone from Dell. >> >>> Am 09.12.2016 um 18:33 schrieb Thomas Gleixner: >>>> Can yo

Re: [PATCH] x86/tsc: RFC: re-synchronize TSCs to boot cpu TSC

Am 09.12.2016 um 23:59 schrieb Thomas Gleixner: > On Fri, 9 Dec 2016, Roland Scheidegger wrote: > > Cc'ed someone from Dell. > >> Am 09.12.2016 um 18:33 schrieb Thomas Gleixner: >>> Can you add the patch below to gather more information? There is a hunk in >>&

Re: [PATCH] x86/tsc: RFC: re-synchronize TSCs to boot cpu TSC

Am 09.12.2016 um 23:59 schrieb Thomas Gleixner: > On Fri, 9 Dec 2016, Roland Scheidegger wrote: > > Cc'ed someone from Dell. > >> Am 09.12.2016 um 18:33 schrieb Thomas Gleixner: >>> Can you add the patch below to gather more information? There is a hunk in >>&

Re: [PATCH] x86/tsc: RFC: re-synchronize TSCs to boot cpu TSC

Am 09.12.2016 um 18:33 schrieb Thomas Gleixner: > On Fri, 9 Dec 2016, Roland Scheidegger wrote: >> Am 09.12.2016 um 10:59 schrieb Thomas Gleixner: >>> On Fri, 9 Dec 2016, Roland Scheidegger wrote: >>>> >>>> I saw some system lockups though: >>>

Re: [PATCH] x86/tsc: RFC: re-synchronize TSCs to boot cpu TSC

Am 09.12.2016 um 18:33 schrieb Thomas Gleixner: > On Fri, 9 Dec 2016, Roland Scheidegger wrote: >> Am 09.12.2016 um 10:59 schrieb Thomas Gleixner: >>> On Fri, 9 Dec 2016, Roland Scheidegger wrote: >>>> >>>> I saw some system lockups though: >>>

Re: [PATCH] x86/tsc: RFC: re-synchronize TSCs to boot cpu TSC

Am 09.12.2016 um 10:59 schrieb Thomas Gleixner: > On Fri, 9 Dec 2016, Roland Scheidegger wrote: >> >> I saw some system lockups though: >> When doing a cold boot, this kernel never managed to boot up. The last >> message seen is: >> x86: Booting SMP configuration:

Re: [PATCH] x86/tsc: RFC: re-synchronize TSCs to boot cpu TSC

Am 09.12.2016 um 10:59 schrieb Thomas Gleixner: > On Fri, 9 Dec 2016, Roland Scheidegger wrote: >> >> I saw some system lockups though: >> When doing a cold boot, this kernel never managed to boot up. The last >> message seen is: >> x86: Booting SMP configuration:

Re: Kernel Freeze with American Megatrends BIOS

On 08/31/16 22:06, Roland Singer wrote: > Here is Peter Wu's reply, which was not send to the mailing list, because > I had to resend my e-mail to him due to a failure... > > > Forwarded Message > Subject: Re: Fwd: Re: Kernel Freeze with American Megatrends BI

Re: Kernel Freeze with American Megatrends BIOS

On 08/31/16 22:06, Roland Singer wrote: > Here is Peter Wu's reply, which was not send to the mailing list, because > I had to resend my e-mail to him due to a failure... > > > Forwarded Message > Subject: Re: Fwd: Re: Kernel Freeze with American Megatrends BI

Re: Kernel Freeze with American Megatrends BIOS

;pe...@lekensteyn.nl> To: Roland Singer <roland.sin...@desertbit.com> On Wed, Aug 31, 2016 at 05:56:18PM +0200, Roland Singer wrote: > > If you look at my notes.txt, you will see that _OFF always executes the > > same code. PGON differs. When the problem occurs, "Q0L0" somehow

Re: Kernel Freeze with American Megatrends BIOS

Here is Peter Wu's reply, which was not send to the mailing list, because I had to resend my e-mail to him due to a failure... Forwarded Message Subject: Re: Fwd: Re: Kernel Freeze with American Megatrends BIOS Date: Wed, 31 Aug 2016 18:08:53 +0200 From: Peter Wu To: Roland

Re: Kernel Freeze with American Megatrends BIOS

>> >> Thanks. Right now I am overriding the DSDT, but I am not able to override >> the SSDT, because I have to fix and compile all the SSDT files. There >> are too many compile errors... Wanted to find the exact line which >> is responsible for the hickup. > > Have you disassembled with externs

Re: Kernel Freeze with American Megatrends BIOS

>> >> Thanks. Right now I am overriding the DSDT, but I am not able to override >> the SSDT, because I have to fix and compile all the SSDT files. There >> are too many compile errors... Wanted to find the exact line which >> is responsible for the hickup. > > Have you disassembled with externs

Re: Kernel Freeze with American Megatrends BIOS

Am 31.08.2016 um 13:46 schrieb Peter Wu: > On Wed, Aug 31, 2016 at 01:27:36PM +0200, Roland Singer wrote: >> Am 30.08.2016 um 21:53 schrieb Peter Wu: >>> On Mon, Aug 29, 2016 at 11:02:10AM -0500, Bjorn Helgaas wrote: >>>> [+cc linux-acpi, linux-kernel, dri-devel] &g

Re: Kernel Freeze with American Megatrends BIOS

Am 31.08.2016 um 13:46 schrieb Peter Wu: > On Wed, Aug 31, 2016 at 01:27:36PM +0200, Roland Singer wrote: >> Am 30.08.2016 um 21:53 schrieb Peter Wu: >>> On Mon, Aug 29, 2016 at 11:02:10AM -0500, Bjorn Helgaas wrote: >>>> [+cc linux-acpi, linux-kernel, dri-devel] &g

Re: Kernel Freeze with American Megatrends BIOS

Am 30.08.2016 um 21:53 schrieb Peter Wu: > On Mon, Aug 29, 2016 at 11:02:10AM -0500, Bjorn Helgaas wrote: >> [+cc linux-acpi, linux-kernel, dri-devel] >> >> Hi Roland, >> >> I have no idea how to debug this problem. Are you seeing something >> that sugge

Re: Kernel Freeze with American Megatrends BIOS

Am 30.08.2016 um 21:53 schrieb Peter Wu: > On Mon, Aug 29, 2016 at 11:02:10AM -0500, Bjorn Helgaas wrote: >> [+cc linux-acpi, linux-kernel, dri-devel] >> >> Hi Roland, >> >> I have no idea how to debug this problem. Are you seeing something >> that sugge

Re: Kernel Freeze with American Megatrends BIOS

Am 30.08.2016 um 21:21 schrieb Peter Wu: > On Tue, Aug 30, 2016 at 02:13:46PM -0400, Ilia Mirkin wrote: >> On Tue, Aug 30, 2016 at 2:02 PM, Roland Singer >> <roland.sin...@desertbit.com> wrote: >>> I configured bbswitch to not set any states automatically...

Re: Kernel Freeze with American Megatrends BIOS

Am 30.08.2016 um 21:21 schrieb Peter Wu: > On Tue, Aug 30, 2016 at 02:13:46PM -0400, Ilia Mirkin wrote: >> On Tue, Aug 30, 2016 at 2:02 PM, Roland Singer >> wrote: >>> I configured bbswitch to not set any states automatically... >>> So it's possible to obta

Re: Kernel Freeze with American Megatrends BIOS

Am 30.08.2016 um 20:13 schrieb Ilia Mirkin: > On Tue, Aug 30, 2016 at 2:02 PM, Roland Singer > <roland.sin...@desertbit.com> wrote: >> I configured bbswitch to not set any states automatically... >> So it's possible to obtain and verify the GPU power state. >> >

Re: Kernel Freeze with American Megatrends BIOS

Am 30.08.2016 um 20:13 schrieb Ilia Mirkin: > On Tue, Aug 30, 2016 at 2:02 PM, Roland Singer > wrote: >> I configured bbswitch to not set any states automatically... >> So it's possible to obtain and verify the GPU power state. >> >> However I removed the bbswitch

Re: Kernel Freeze with American Megatrends BIOS

Am 30.08.2016 um 20:09 schrieb Emil Velikov: > I second Ilia here. Using bbswitch in conjunction with any driver (be > that nouveau or the proprietary one) is a bad idea. > I removed bbswitch from my system and will use vgaswitcheroo to check the GPU power state from now. > (If Ilia's

Re: Kernel Freeze with American Megatrends BIOS

Am 30.08.2016 um 20:09 schrieb Emil Velikov: > I second Ilia here. Using bbswitch in conjunction with any driver (be > that nouveau or the proprietary one) is a bad idea. > I removed bbswitch from my system and will use vgaswitcheroo to check the GPU power state from now. > (If Ilia's

Re: Kernel Freeze with American Megatrends BIOS

log messages as send before. Am 30.08.2016 um 19:43 schrieb Ilia Mirkin: > On Tue, Aug 30, 2016 at 1:37 PM, Roland Singer > <roland.sin...@desertbit.com> wrote: >> My conclusion: >> >> 1. Nouveau has couple of problems with GTX 9** M Nvidia GPUs. >>I w

Re: Kernel Freeze with American Megatrends BIOS

log messages as send before. Am 30.08.2016 um 19:43 schrieb Ilia Mirkin: > On Tue, Aug 30, 2016 at 1:37 PM, Roland Singer > wrote: >> My conclusion: >> >> 1. Nouveau has couple of problems with GTX 9** M Nvidia GPUs. >>I would love to help here. > >

Re: Kernel Freeze with American Megatrends BIOS

but other things break... What the hell is going on?! :/ Am 30.08.2016 um 17:48 schrieb Emil Velikov: > On 30 August 2016 at 16:25, Roland Singer <roland.sin...@desertbit.com> wrote: >> I tried these scenarios: >> >> 1. Booted the system without the bbswitch module.

Re: Kernel Freeze with American Megatrends BIOS

but other things break... What the hell is going on?! :/ Am 30.08.2016 um 17:48 schrieb Emil Velikov: > On 30 August 2016 at 16:25, Roland Singer wrote: >> I tried these scenarios: >> >> 1. Booted the system without the bbswitch module. The nouveau module >>was loa

Re: Kernel Freeze with American Megatrends BIOS

, then it is not the video driver nor bbswitch. Am 30.08.2016 um 16:08 schrieb Emil Velikov: > On 30 August 2016 at 14:06, Bjorn Helgaas <helg...@kernel.org> wrote: >> On Tue, Aug 30, 2016 at 12:08:57PM +0200, Roland Singer wrote: >>> Thanks for pointing it out. >>>

Re: Kernel Freeze with American Megatrends BIOS

, then it is not the video driver nor bbswitch. Am 30.08.2016 um 16:08 schrieb Emil Velikov: > On 30 August 2016 at 14:06, Bjorn Helgaas wrote: >> On Tue, Aug 30, 2016 at 12:08:57PM +0200, Roland Singer wrote: >>> Thanks for pointing it out. >>> >>> Yeah that's

Re: Kernel Freeze with American Megatrends BIOS

ny hints how to continue debugging? Cheers, Roland Am 30.08.2016 um 01:54 schrieb Bjorn Helgaas: > On Mon, Aug 29, 2016 at 09:55:56PM +0200, Roland Singer wrote: >> Just tried it and the system didn't freeze. However it will freeze >> after some time (few minutes while working). >> >

Re: Kernel Freeze with American Megatrends BIOS

ny hints how to continue debugging? Cheers, Roland Am 30.08.2016 um 01:54 schrieb Bjorn Helgaas: > On Mon, Aug 29, 2016 at 09:55:56PM +0200, Roland Singer wrote: >> Just tried it and the system didn't freeze. However it will freeze >> after some time (few minutes while working). >> >

Re: Kernel Freeze with American Megatrends BIOS

Just tried it and the system didn't freeze. However it will freeze after some time (few minutes while working). Seams to be pci_read_config_dword. Where is this exactly defined? Am 29.08.2016 um 21:07 schrieb Bjorn Helgaas: > On Mon, Aug 29, 2016 at 08:46:17PM +0200, Roland Singer wrote: &g

Re: Kernel Freeze with American Megatrends BIOS

Just tried it and the system didn't freeze. However it will freeze after some time (few minutes while working). Seams to be pci_read_config_dword. Where is this exactly defined? Am 29.08.2016 um 21:07 schrieb Bjorn Helgaas: > On Mon, Aug 29, 2016 at 08:46:17PM +0200, Roland Singer wrote: &g

Re: Kernel Freeze with American Megatrends BIOS

.com/Bumblebee-Project/bbswitch/blob/master/bbswitch.c#L333 Am 29.08.2016 um 18:02 schrieb Bjorn Helgaas: > [+cc linux-acpi, linux-kernel, dri-devel] > > Hi Roland, > > I have no idea how to debug this problem. Are you seeing something > that suggests it may be a PCI problem? >

Re: Kernel Freeze with American Megatrends BIOS

.com/Bumblebee-Project/bbswitch/blob/master/bbswitch.c#L333 Am 29.08.2016 um 18:02 schrieb Bjorn Helgaas: > [+cc linux-acpi, linux-kernel, dri-devel] > > Hi Roland, > > I have no idea how to debug this problem. Are you seeing something > that suggests it may be a PCI problem? >

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

On Fri, Jul 8, 2016 at 9:51 AM, Jason Gunthorpe wrote: > So, it appears, the dst and neigh can be used for all performances cases. > > For the non performance dst == null case, can we just burn cycles and > stuff the daddr in front of the packet at hardheader

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

On Fri, Jul 8, 2016 at 9:51 AM, Jason Gunthorpe wrote: > So, it appears, the dst and neigh can be used for all performances cases. > > For the non performance dst == null case, can we just burn cycles and > stuff the daddr in front of the packet at hardheader time, even if we > have to copy? OK,

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

On Thu, Jul 7, 2016 at 4:14 PM, Jason Gunthorpe wrote: > We have neighbour_priv, and ndo_neigh_construct/destruct now .. > > A first blush that would seem to be enough to let ipoib store the AH > and other path information in the neigh and avoid the cb? At least

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

On Thu, Jul 7, 2016 at 4:14 PM, Jason Gunthorpe wrote: > We have neighbour_priv, and ndo_neigh_construct/destruct now .. > > A first blush that would seem to be enough to let ipoib store the AH > and other path information in the neigh and avoid the cb? At least the > example in clip sure looks

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

>> struct skb_gso_cb { >> int mac_offset; >> int encap_level; >> __u16 csum_start; >> }; > This is based on an out-dated version of this struct. The 4.7 RC > kernel has a few more fields that were added to support local checksum > offload for encapsulated

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

>> struct skb_gso_cb { >> int mac_offset; >> int encap_level; >> __u16 csum_start; >> }; > This is based on an out-dated version of this struct. The 4.7 RC > kernel has a few more fields that were added to support local checksum > offload for encapsulated

Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

On Thu, Jan 7, 2016 at 3:00 AM, Konstantin Khlebnikov wrote: > Or just shift GSO CB and add couple checks like > BUILD_BUG_ON(sizeof(SKB_GSO_CB(skb)->room) < sizeof(*IPCB(skb))); Resurrecting this old thread, because the patch that ultimately went upstream (commit 9207f9d45b0a

Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

On Thu, Jan 7, 2016 at 3:00 AM, Konstantin Khlebnikov wrote: > Or just shift GSO CB and add couple checks like > BUILD_BUG_ON(sizeof(SKB_GSO_CB(skb)->room) < sizeof(*IPCB(skb))); Resurrecting this old thread, because the patch that ultimately went upstream (commit 9207f9d45b0a / net: preserve IP

[PATCH] iommu/vt-d: Don't reject NTB devices due to scope mismatch

From: Roland Dreier <rol...@purestorage.com> On a system with an Intel PCIe port configured as an NTB device, iommu initialization fails with DMAR: Device scope type does not match for :80:03.0 This is because the DMAR table reports this device as having s

  1   2   3   4   5   6   7   8   9   10   >