>On Mon 23 Apr 19:48 PDT 2018, Chanwoo Choi wrote:
>
>> Hi,
>>
>> On 2018??? 04??? 24??? 09:20, Bjorn Andersson wrote:
>> > The code in devfreq_add_device() handles the case where a freq_table is
>> > passed by the client, but then requests min and max frequences from
>> > the, in this case absent
On Mon 23 Apr 19:48 PDT 2018, Chanwoo Choi wrote:
> Hi,
>
> On 2018??? 04??? 24??? 09:20, Bjorn Andersson wrote:
> > The code in devfreq_add_device() handles the case where a freq_table is
> > passed by the client, but then requests min and max frequences from
> > the, in this case absent, opp ta
Hi,
On 2018년 04월 24일 09:20, Bjorn Andersson wrote:
> The code in devfreq_add_device() handles the case where a freq_table is
> passed by the client, but then requests min and max frequences from
> the, in this case absent, opp tables.
>
> Read the min and max frequencies from the frequency table,
With the introduction of f1d981eaecf8 ("PM / devfreq: Use the available min/max
frequency") the UFS host controller driver (UFSHCD) stopped probing for
platforms that supports frequency scaling, e.g. all modern Qualcomm platforms.
The cause of this was UFSHCD's reliance of not registering any freq
Failing to register with devfreq leaves hba->devfreq assigned, which
causes the error path to dereference the ERR_PTR(). Rather than bolting
on more conditionals, move the call of devm_devfreq_add_device() into
it's own function and only update hba->devfreq once it's successfully
registered.
The s
devfreq requires that the client operates on actual frequencies, not
only 0 and UMAX_INT and as such UFS brok with the introduction of
f1d981eaecf8 ("PM / devfreq: Use the available min/max frequency").
This patch registers the frequencies of the first clock with devfreq and
use these to determine
The code in devfreq_add_device() handles the case where a freq_table is
passed by the client, but then requests min and max frequences from
the, in this case absent, opp tables.
Read the min and max frequencies from the frequency table, which has
been built from the opp table if one exists, instea
https://bugzilla.kernel.org/show_bug.cgi?id=199435
--- Comment #15 from Don (don.br...@microsemi.com) ---
(In reply to Anthony Hausman from comment #11)
> The only patch that I'm sure that I have is the "scsi: hpsa: fix selection
> of reply queue" one.
> For the I'm using an out of the box 4.11 ke
God dag,
Jeg er administrerende direktør i industri- og handelsbanken i Kina
(ICBC). Jeg har et gjensidig forretningsforslag, som refererer til overføring
av a stor mengde penger til en konto i utlandet, med din hjelp som utlending
partner som mottaker av midlene. Alt om denne transaksjonen
vil b
Thanks, James. The idea of cutting communications with Scsi_Host at
bsg_unregister_queue(..) time and leaving bsg_class_device to
its own fate makes a lot of sense, conceptually. But there are
implementation issues that are difficult to work around.
bsg.c creates bsg_class_device and takes a refer
Hi,
We are running kernel 4.4.0-22 and the patch below does not seem to be present
in the mpt3sas driver. Can you please confirm?
As a reminder the patch was related to a Security Erase ATA command that
requires a very long timeout like 100 minutes or more and the drive retains a
busy status. A
On Mon, 23 Apr 2018 14:43:13 +0200
Steffen Maier wrote:
> > - TP_printk("[%s] %d", __entry->comm, __entry->nr_rq)
> > + TP_printk("[%s] %d %s", __entry->comm, __entry->nr_rq,
> > + __entry->explicit ? "Sync" : "Async")
> > );
> >
> > /**
>
> This entire hunk does not seem
On 04/17/2018 12:00 PM, Bean Huo (beanhuo) wrote:
#Cat trace
iozone-4055 [000] 665.039276: block_unplug: [iozone] 1 Sync
iozone-4055 [000] ...1 665.039278: block_rq_insert: 8,48 WS 0 () 39604352 +
128 tag=18 [iozone]
iozone-4055 [000] ...1 665.039280: block_rq_issue: 8,48 WS 0 ()
On 04/16/2018 04:33 PM, Bean Huo (beanhuo) wrote:
Print the request tag along with other information in block trace events
when tracing request , and unplug type (Sync / Async).
Signed-off-by: Bean Huo
---
include/trace/events/block.h | 36 +---
1 file change
On 04/19/2018 10:18 PM, Omar Sandoval wrote:
> On Thu, Apr 19, 2018 at 01:44:41PM -0600, Jens Axboe wrote:
>> On 4/19/18 1:41 PM, Bart Van Assche wrote:
>>> On Thu, 2018-04-19 at 12:13 -0700, Omar Sandoval wrote:
On Thu, Apr 19, 2018 at 11:53:30AM -0700, Omar Sandoval wrote:
> Thanks for
Martin,
Please see my replies inline.
Thanks,
Chaitra
-Original Message-
From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
Sent: Saturday, April 21, 2018 3:52 AM
To: Chaitra P B
Cc: linux-scsi@vger.kernel.org; sathya.prak...@broadcom.com;
sreekanth.re...@broadcom.com; suganat
https://bugzilla.kernel.org/show_bug.cgi?id=199435
--- Comment #14 from Anthony Hausman (anthonyhaussm...@gmail.com) ---
Indeed I have a charged battery (capacitor) and the writeback-cache enabled.
I run the hp-health component too, I have already try to disable it on the 4.11
kernel and have repr
> On 23. Apr 2018, at 10:28, Kashyap Desai wrote
>>
>> Just did that on the “Dell R730xd, MegaRAID SAS-3 3108” and get the
>> following output when the megacli works fine.
>>
>> ###
>> Apr 23 09:31:37 xh643 kernel: [ 368.319092] GD IOV-len: 2048 Apr 23
>> 09:31:37
>> xh643 kernel: [ 368.31942
>
> Interesting. What is considered old and new? I have a third machine "Dell
> R515, MegaRAID SAS 2108”, is that considered new? Its running the same
> Xen/Kernel/Megacli-versions as the other two, but the error does not
> occur.
Nope this is also old controller. When I say new controller, It is
On 19. Apr 2018, at 08:33, Kashyap Desai wrote:
>
> I think you may see issue with 4.6 kernel as well. This is run time memory
> allocation failure. Older controller used 32 bit consistence DMA mask, so
> possibility of memory allocation failure is high compare to 64 bit
> consistence DMA mask. N
20 matches
Mail list logo
