search for: resch

Full_Name: Wolfgang Resch Version: R 2.8.1 GUI 1.27 OS: OS X 10.4.11 Submission from: (NULL) (137.187.89.14) Strange behavior of qbinom: > qbinom(0.01, 5016279, 1e-07) [1] 0 > qbinom(0.01, 5016279, 2e-07) [1] 16 > qbinom(0.01, 5016279, 3e-07) [1] 16 > qbinom(0.01, 5016279, 4e-07) [1] 16 > qbinom(0.01, 501...

On 1/9/2015 3:06 AM, Philipp Resch <philipp at devh.de> wrote: > It seems as if claws mail is preferring SSLv3 And since dovecot is really not affected by the poodle vulnerability, if you can't upgrade (I believe 2.2 is in the backports repo?), probably easiest to just reenable SSLv3...

...cot/dovecot.conf line 136: Unknown setting: ssl_prefer_server_ciphers and if trying to comment the line with 'ssl_prefer_server_ciphers', dovecot restarts fine but same problem as before, claws-mail can't connect. dovecot version is 2.1.7 any hints ? On 2015-01-09 07:50, Philipp Resch wrote: > Am 09.01.2015 um 08:07 schrieb ml at ruggedinbox.com: >> Hi all, when hardening dovecot against the POODLE vulnerability, >> we followed the advise to disable SSL2 and SSL3 >> but this is giving problems with some email clients (claws-mail). >> >> ssl_prot...

Am 04.08.2014 um 17:09 schrieb Maarten Lankhorst: > op 04-08-14 17:04, Christian K?nig schreef: >> Am 04.08.2014 um 16:58 schrieb Maarten Lankhorst: >>> op 04-08-14 16:45, Christian K?nig schreef: >>>> Am 04.08.2014 um 16:40 schrieb Maarten Lankhorst: >>>>> op 04-08-14 16:37, Christian K?nig schreef: >>>>>>> It'a pain to deal

...q.lock, irqflags); > + radeon_irq_set(rdev); > + spin_unlock_irqrestore(&rdev->irq.lock, irqflags); > +} > + > /** > * radeon_gpu_reset - reset the asic > * > @@ -1624,6 +1673,7 @@ int radeon_gpu_reset(struct radeon_device *rdev) > > int i, r; > int resched; > + uint32_t sw_mask; > > down_write(&rdev->exclusive_lock); > > @@ -1637,6 +1687,7 @@ int radeon_gpu_reset(struct radeon_device *rdev) > radeon_save_bios_scratch_regs(rdev); > /* block TTM */ > resched = ttm_bo_lock_delayed_workqueue(&rdev->mman.b...

...ng_int[i]); + } + + spin_lock_irqsave(&rdev->irq.lock, irqflags); + radeon_irq_set(rdev); + spin_unlock_irqrestore(&rdev->irq.lock, irqflags); +} + /** * radeon_gpu_reset - reset the asic * @@ -1624,6 +1673,7 @@ int radeon_gpu_reset(struct radeon_device *rdev) int i, r; int resched; + uint32_t sw_mask; down_write(&rdev->exclusive_lock); @@ -1637,6 +1687,7 @@ int radeon_gpu_reset(struct radeon_device *rdev) radeon_save_bios_scratch_regs(rdev); /* block TTM */ resched = ttm_bo_lock_delayed_workqueue(&rdev->mman.bdev); + sw_mask = radeon_gpu_mask_sw_i...

...truct nouveau_dvfs_dev_status status; > + u32 utilization = 0; > + int state, ret; > + > + ret = impl->get_dev_status(dvfs, &status); > + if (ret) { > + nv_warn(dvfs, "failed to get device status\n"); > + goto resched; > + } > + > + if (status.total) > + utilization = div_u64((u64)status.busy * 100, status.total); > + > + data->avg_load = (data->p_smooth * data->avg_load) + utilization; > + data->avg_load /= data->p_smooth + 1; > +...

...ng_int[i]); + } + + spin_lock_irqsave(&rdev->irq.lock, irqflags); + radeon_irq_set(rdev); + spin_unlock_irqrestore(&rdev->irq.lock, irqflags); +} + /** * radeon_gpu_reset - reset the asic * @@ -1624,6 +1673,7 @@ int radeon_gpu_reset(struct radeon_device *rdev) int i, r; int resched; + uint32_t sw_mask; down_write(&rdev->exclusive_lock); @@ -1637,6 +1687,7 @@ int radeon_gpu_reset(struct radeon_device *rdev) radeon_save_bios_scratch_regs(rdev); /* block TTM */ resched = ttm_bo_lock_delayed_workqueue(&rdev->mman.bdev); + sw_mask = radeon_gpu_mask_sw_i...

...u32 utilization = 0; >>> + int state, ret; >>> + >>> + ret = impl->get_dev_status(dvfs, &status); >>> + if (ret) { >>> + nv_warn(dvfs, "failed to get device status\n"); >>> + goto resched; >>> + } >>> + >>> + if (status.total) >>> + utilization = div_u64((u64)status.busy * 100, >>> status.total); >>> + >>> + data->avg_load = (data->p_smooth * data->avg_load) + utilization; >&...

There might be some callers of nouveau_clock_astate(), and they are from inetrrupt context. So we must ensure that this function can be atomic in that condition. This patch adds one parameter which is subsequently passed to nouveau_pstate_calc(). Therefore we can choose whether we want to wait for the pstate work's completion or not. Signed-off-by: Vince Hsu <vinceh at nvidia.com> ---

Hi, This is a try to have some simple DVFS (Dynamic Voltage and Frequency Scaling) support for GK20A. Instead of relying on other existing frequency scaling framework, we create a simple subdev in Nouveau for the same purpose. That's because we don't want to make the DVFS implementation for GK20A far more than enough in the beginning and hinder the implementation for dGPU in the future.

Am 19.05.2014 15:35, schrieb Maarten Lankhorst: > op 19-05-14 14:30, Christian K?nig schreef: >> Am 19.05.2014 12:10, schrieb Maarten Lankhorst: >>> op 19-05-14 10:27, Christian K?nig schreef: >>>> Am 19.05.2014 10:00, schrieb Maarten Lankhorst: >>>> [SNIP] >>>> The problem here is that the whole approach collides with the way >>>>

...= nv_object(dvfs); + struct nouveau_dvfs_impl *impl = (void *)object->oclass; + struct nouveau_dvfs_dev_status status; + u32 utilization = 0; + int state, ret; + + ret = impl->get_dev_status(dvfs, &status); + if (ret) { + nv_warn(dvfs, "failed to get device status\n"); + goto resched; + } + + if (status.total) + utilization = div_u64((u64)status.busy * 100, status.total); + + data->avg_load = (data->p_smooth * data->avg_load) + utilization; + data->avg_load /= data->p_smooth + 1; + nv_trace(dvfs, "utilization = %d %%, avg_load = %d %%\n", + utiliza...

...larm) > nvkm_trace(subdev, "utilization = %d %%, avg_load = %d %%\n", > utilization, data->avg_load); > > - ret = gk20a_pmu_dvfs_get_cur_state(pmu, &state); > - if (ret) { > - nvkm_warn(subdev, "failed to get current state\n"); > - goto resched; > - } > - > if (gk20a_pmu_dvfs_get_target_state(pmu, &state, data->avg_load)) { > nvkm_trace(subdev, "set new state to %d\n", state); > gk20a_pmu_dvfs_target(pmu, &state);

...[i]); + } + + spin_lock_irqsave(&rdev->irq.lock, irqflags); + radeon_irq_set(rdev); + spin_unlock_irqrestore(&rdev->irq.lock, irqflags); +} + /** * radeon_gpu_reset - reset the asic * @@ -1582,6 +1631,7 @@ int radeon_gpu_reset(struct radeon_device *rdev) int i, r; int resched; + uint32_t sw_mask; down_write(&rdev->exclusive_lock); @@ -1595,6 +1645,7 @@ int radeon_gpu_reset(struct radeon_device *rdev) radeon_save_bios_scratch_regs(rdev); /* block TTM */ resched = ttm_bo_lock_delayed_workqueue(&rdev->mman.bdev); + sw_mask = radeon_gpu_mas...

...flags); > + radeon_irq_set(rdev); > + spin_unlock_irqrestore(&rdev->irq.lock, irqflags); > +} > + > /** > * radeon_gpu_reset - reset the asic > * > @@ -1582,6 +1631,7 @@ int radeon_gpu_reset(struct radeon_device *rdev) > > int i, r; > int resched; > + uint32_t sw_mask; > > down_write(&rdev->exclusive_lock); > > @@ -1595,6 +1645,7 @@ int radeon_gpu_reset(struct radeon_device *rdev) > radeon_save_bios_scratch_regs(rdev); > /* block TTM */ > resched = ttm_bo_lock_delayed_workqueue(&rd...

...s status; >> + u32 utilization = 0; >> + int state, ret; >> + >> + ret = impl->get_dev_status(dvfs, &status); >> + if (ret) { >> + nv_warn(dvfs, "failed to get device status\n"); >> + goto resched; >> + } >> + >> + if (status.total) >> + utilization = div_u64((u64)status.busy * 100, status.total); >> + >> + data->avg_load = (data->p_smooth * data->avg_load) + utilization; >> + data->avg_load /= data...

...>>>> + int state, ret; >>>> + >>>> + ret = impl->get_dev_status(dvfs, &status); >>>> + if (ret) { >>>> + nv_warn(dvfs, "failed to get device status\n"); >>>> + goto resched; >>>> + } >>>> + >>>> + if (status.total) >>>> + utilization = div_u64((u64)status.busy * 100, >>>> status.total); >>>> + >>>> + data->avg_load = (data->p_smooth * data->av...

commit f8e617f4582995f7c25ef25b4167213120ad122b ("sched/idle/x86: Optimize unnecessary mwait_idle() resched IPIs") adds memory barriers around clflush, but this seems wrong for UP since barrier() has no effect on clflush. We really want mfence so switch to mb() instead. Cc: Mike Galbraith <bitbucket at online.de> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- arch/x86/kern...

On 2015-01-09 08:34, Charles Marcus wrote: > On 1/9/2015 3:06 AM, Philipp Resch <philipp at devh.de> wrote: >> It seems as if claws mail is preferring SSLv3 > > And since dovecot is really not affected by the poodle vulnerability, > if > you can't upgrade (I believe 2.2 is in the backports repo?), probably > easiest to just reenable SSLv3......